Desenvolvimento Cliente-Servidor
Numa aplicação cliente-servidor o cliente (aquele que instancia a interface do aplicativo) liga-se a um sistema de base de dados. Características comuns de sistemas cliente-servidor:
- Normalmente aplicações desse tipo utilizam programação estruturada, ao invés de programação orientada a objetos;
- A regra de negócio é dividida entre o servidor (banco de dados) e o cliente (a aplicação em si).
Vantagens:
- Velocidade de entrega: Aplicações que utilizam a abordagem cliente-servidor em geral apresentam como vantagem a rapidez com que a ‘primeira versão’ pode ser construída. A desvantagem está justamente na manutenção desta primeira versão, visto que as regras de negócio (a inteligência da aplicação) ficam distribuídas entre cliente e servidor, e no caso do cliente, as regras ficam misturadas com o código responsável pela interface (GUI) da aplicação.
- Curva de aprendizado e custo: A técnica cliente-servidor é mais fácil de dominar, e apresenta menor curva de aprendizado. Por esse motivo, é mais barato montar uma equipe para produzir aplicações deste modelo.
Desvantagens:
- Manutenção: Como citado acima as regras de negócio ficam distribuídas entre o cliente e o servidor; Além disso, as regras do lado cliente ficam misturadas com a lógica de interface, dificultando a manutenção e evolução do software.
- Gargalo: Outro ponto negativo é que a aplicação cliente precisa estar _todo_o_tempo_ conectada com a aplicação servidora. Além de criar um gargalo no processamento, se o servidor cair, todos os clientes conectados também caem.
Especificação por linguagem de desenvolvimento
Desenvolvimento cliente/servidor com Delphi - A maior parte das aplicações construídas em Delphi seguem o padrão cliente-servidor;
Um cenário típico de aplicação Delphi cliente-servidor segue a estrutura abaixo:
|
Camada Banco de Dados (Servidor) Firebird e InterBase são os bancos mais utilizados com Delphi; Uma parte das regras de negócio da aplicação é codificada dentro do banco de dados, através de stored procedures e triggers |
|
Camada Cliente – Aplicação desktop Win32 O acesso a dados é feito através de bridges de acesso, tais como: BDE, dbExpress, IBX, ADO. Uma parte das regras de negócio é codificada na aplicação Win32. |
Desenvolvimento em camadas com orientação a objetos e ECO - Este cenário de desenvolvimento Delphi segue o padrão DAO (data access objects) onde temos um modelo multicamadas, contendo: banco de dados, servidor web (contendo classes de domínio e classes de negócio), camada de persistência e interface (browser). O ECO gerencia automaticamente a criação e manutenção da camada de persistência.
Vantagens:
- Separação lógica entre as partes da aplicação, o que torna o software mais flexível e fácil de manter;
- Reutilização de código (por exemplo uma mesma validação ou regra de negócio pode ser reutizada em diferentes tipos de interface de usuário);
- Melhor uso de técnicas de POO, por utilizar o ECO, a programação se torna totalmente orientada a objetos e deixa de ser totalmente orientada a eventos;
- Menor impacto na mudança de requisito e redução de custos. Uma solicitação de alteração, por parte do cliente, despenderá um esforço muito menor por parte da equipe de desenvolvimento (muitas vezes o ECO faz a maior parte do trabalho), se comparado a um software desenvolvido usando tecnologias tradicionais.
Desvantagens:
- Maior investimento em aprendizado e custo do profissional mais caro que a média;
- Queda na velocidade de produção da “primeira versão”.
- O desenvolvimento fica ‘preso’ ao ambiente ECO;
procedure TWebForm1.btnSalvar_Click(
sender: System.Object; e: System.EventArgs);
var
obj: Usuario;
begin
obj := Usuario.Create(EcoSpace);
obj.Nome := txtUsuario.Text;
obj.Endereco := txtEndereco.Text;
obj.Email := txtEmail.Text;
obj.Senha := txtSenha.Text;
UpdateDatabase;
Response.Redirect('Home.aspx');
end;
Metodologia
A aplicação desenvolvida sobre um modelo multicamadas, temos: banco de dados, aplicação web (o servidor), camada de persistência e interface (browser). O Modelo no entanto não segue o padrão MVC. Existe uma camada de negócio (Business Logic que é gerada pelo modelo UML construído pelo ECO. De fato, o ECO gera a maioria do código de negócio, com com classes e regras de acordo com a definição do modelo.
Devido a utilização do ECO, a programação utilizada será completamente orientada a objetos (OO). As vantagens dessa abordagem são muitas:
- Separação lógica entre as partes da aplicação, o que torna o software mais flexível e fácil de manter;
- Reutilização de código (por exemplo uma mesma validação ou regra de negócio pode ser reutilizada em diferentes tipos de interface de usuário);
- Melhor uso de técnicas de POO, por utilizar o ECO, a programação se torna totalmente orientada a objetos e deixa de ser totalmente orientada a eventos;
- Menor impacto na mudança de requisito e redução de custos. Uma solicitação de alteração, por parte do cliente, despenderá um esforço muito menor por parte da equipe de desenvolvimento (muitas vezes o ECO faz a maior parte do trabalho), se comparado a um software desenvolvido usando tecnologias tradicionais.
Desvantagens:
- Investimento em aprendizado;
- Queda na velocidade de produção da “primeira versão”.
- O desenvolvimento fica “‘preso” ao ambiente ECO;
A lógica de negócio representada no modelo UML garante a independência de interface de usuário podendo ser exposta através de um webform, de um WebService ou até mesmo de um Windows Form. Nesse caso as interfaces utilizariam as classes definidas no modelo UML criando uma maneira do usuário interagir com elas. Esta é a função de uma camada de apresentação, apenas permitir a interação do usuário com a lógica do sistema.
Para desenvolver utilizando essa metodologia é preciso tem em mente o conceito de camadas lógicas. Cada camada é responsável por uma área e elas trocam informações entre si. As áreas de uma aplicação são divididas de acordo com o entendimento de cada um, porém quanto ao ECO podemos relacionar as seguintes:
- Banco de dados – O Banco de Dados é utilizado para armazenamento dos objetos. O próprio ECO se responsabiliza pela adequação da estrutura do banco de dados em relação ao modelo de objetos.
- Domínio – As classes são armazenadas em um “pacote UML”, um arquivo PAS que contém além das classes de domínio, classes e atributos que definem o modelo UML da regra de negócio, como relacionamentos e constraints.
- Persistência – O ECO oferece um conjunto de classes para realização da persistência dos objetos no banco de dados, se encarregando da mesma, retirando assim do desenvolvedor essa obrigação. Veja um exemplo de como persistir um objeto “Usuario”.
Desenvolvimento Multicamadas
No Delphi, o desenvolvimento multicamadas é feito através da tecnologia DataSnap. A principal característica de uma arquitetura multitier, se comparada a client/Server, é o surgimento de uma camada intermediária, também conhecida como middlewareou servidor de aplicação.
Como banco de dados, podemos ter Interbase, Firebird, Oracle, DB2, ou qualquer outro banco suportado pelas tecnologias de acesso com o Delphi. Quem se encarrega da comunicação com o banco de dados é a camada intermediária, a camada lógica de negócio. As aplicações cliente, também conhecidas como thin-clients (clientes leves), não enxergam o banco de dados diretamente.
Para programar de forma multicamadas como DataSnap (antes do Delphi 6 conhecido também como MIDAS), precisamos fazer uso de um protocolo de comunicação. Os protocolos atualmente suportados pelo DataSnap são:
- DCOM
- COM+
- SOAP (Web Services)
- Sockets
A figura abaixo demonstra um exemplo de arquitetura multicamadas com o Delphi, usando Interbase como banco de dados e COM+ como tecnologia de transporte. Essa arquitetura é recomendada para ambientes intranet, com ganho enorme de desempenho e escalabilidade.
A figura abaixo mostra um arquitetura multicamadas utilizando SOAP e Firebird.
As vantagens do desenvolvimento multicamadas com Delphi e DataSnap são muitas:
- Independência de banco de dados: como os clientes não enxergam o banco de dados, apenas o servidor de aplicação, sua solução não fica presa por exemplo ao Interbase, Firebird, SQL Server etc.;
- Centralização das regras de negócio: toda regra da aplicação, como cálculos e validações, pode residir no servidor de aplicação. A mudança de uma regra é enxergada instantaneamente e não há necessidade de recompilação e redistribuição das aplicações cliente;
- Escalabilidade: em arquiteturas como o COM+, o servidor consegue atender a centenas de usuários utilizando algumas poucas conexões com o banco de dados, além de centralizar todo o processamento e acesso no servidor. Com isso, há ganho de performance e escalabilidade;
- Clientes-leves: aplicações clientes não contém praticamente código, apenas o necessário para exibir dados e tratar da interface de usuário. A maioria das funcionalidades ficam no servidor de aplicação;
- No caso do SOAP, uma vantagem na localização geográfica, visto que tudo pode ser acessado pela internet. Filiais em diferentes estados podem acessar uma matriz central sem a necessidade de sincronização de banco de dados, replicação etc. Tudo é acessado em tempo-real;
- Independência de tecnologia cliente: é possível criar diferentes tipos de aplicações cliente, Web, Desktop, Mobile, que acessam o mesmo servidor de aplicação e compartilham as mesmas regras;
- Migração facilitada: se for preciso migrar de tecnologia (SOAP, COM+, Socket) ou mesmo o tipo de banco de dados, poucas partes da arquitetura precisam ser modificadas, pois são independentes.
