Imprimir Post

Arquitetura em Camadas (Parte 1) – Modelo de Desenvolvimento em Camadas

Resumo:

O objetivo desta série é apresentar a Arquitetura em Camadas e os Modelos de Desenvolvimento em Camadas sobre o olhar de seu histórico evolutivo.

Ao final será apresentado um exemplo prático voltado à plataforma .NET, através do modelo conhecido como 3-Tier (aplicação em 3 camadas).

Observação: A publicação desta série será dividida em quatro partes:

  • Teoria: Arquitetura em Camadas (Parte 1) – Modelo de Desenvolvimento em Camadas;
  • Teoria: Arquitetura em Camadas (Parte 2) – Modelo de Desenvolvimento em Camadas;
  • Prática: Arquitetura em Camadas (Parte 3) – Modelo em 3 camadas (3-tier);
  • Prática: Arquitetura em Camadas (Parte 4) – Provisão da Aplicação;
  • Final: Arquitetura em Camadas – Encerramento;

Palavras-chaves:

Arquitetura, Camadas, Desenvolvimento, Cliente, Servidor.

Texto:

Em Arquitetura de Software existem os tipos ou modelos de Arquitetura, disponíveis estes como estruturas de organização que podem ser adotados por determinado meio corporativo.

Modelo Cliente/Servidor ou Client/Server é conhecido pela maioria dos profissionais de T.I e, ainda hoje, é adotado como base de sustentação organizacional dentro de determinadas empresas. Criado pela empresa Xerox PARC (mesma inventora da Interface Gráfica) nos anos 70, surgiu com o objetivo de distribuir cargas de processamento, compartilhar dados e recursos através de poderosos computadores chamados Servidores (Servers), para os que poderiam obter estes serviços com máquinas mais simples, os Clientes (Clients).

Modelo de Desenvolvimento em Camadas - Terminologia - Computadores e Máquinas

Até então, foi citado o modelo lógico da Arquitetura Cliente/Servidor, porém para apresentá-lo com mais claridade, será necessário invadir o espaço da disciplina Redes de Computadores, ilustrando o arranjo do modelo com a seguinte representação:

Modelo de Desenvolvimento em Camadas - Modelo de Arquitetura Cliente/Servidor

Modelo de Arquitetura Cliente/Servidor

No cenário acima, o modelo Cliente/Servidor foi exemplificado em uma topologia onde existem 4 máquinas Cliente e 3 Servidores, sendo estes: Servidor de Arquivos, Servidor de Banco de Dados e Servidor de Impressão.

Modelo de Desenvolvimento em 2 Camadas

A princípio, no modelo Cliente/Servidor, as Aplicações eram implementadas com o chamado modelo de desenvolvimento em duas camadas.

Modelo de Desenvolvimento em Camadas - Terminologia - Aplicativos, Aplicações, Software ou Programas

Desenvolvidos geralmente com Visual Basic, Delphi ou Clarion, os aplicativos no modelo de desenvolvimento em duas camadas eram instalados em cada Cliente (aplicação Cliente) que fariam seu uso, acessando os dados em um Servidor de Banco de Dados.

Modelo de Desenvolvimento em Camadas - Atenção - Modelo de Arquitetura e Modelo de Desenvolvimento

A denominação 2 camadas vem da divisão de responsabilidades. O Cliente com a responsabilidade pela camada que envolve as 2 funções retratadas abaixo:

Apresentação: código que gera a Interface de Usuário (UI) do aplicativo, tornando-o acessível para estes. Em resumo, elementos visuais estão contidos no código da aplicação Cliente.

Lógica do Negócio: regras que se encarregam das atividades relacionadas com os processos de negócio, desde exemplos como: exigências de senhas com um mínimo de caracteres especiais, até como será feito um controle de estoque, cálculos de comissão, descontos para clientes, permissão de acessos à determinada funcionalidade, alteração de legislação, entre outros.

E o Servidor, terá a responsabilidade de armazenar a camada Banco de Dados.

Modelo de Desenvolvimento em Camadas - Modelo de Arquitetura Cliente/Servidor - Modelo de Desenvolvimento em 2 camadas

Modelo de Arquitetura Cliente/Servidor – Modelo de Desenvolvimento em 2 camadas

Com o tempo notou-se muitas desvantagens com o modelo de desenvolvimento em duas camadas, eis abaixo a descrição de algumas delas:

  • Manutenção:

Como a aplicação está contida no Cliente, basta que um formulário de interface mude ou uma lógica de negócio seja alterada, para que todas as aplicações Cliente precisem de atualização, neste caso gerando desvantagem na Manutenção (pode-se imaginar o trabalho no cenário onde um ambiente possua 1000 máquinas Cliente?) e dificuldade em manter-se um Controle de Versão apurado.

  • Conflitos entre aplicações:

Por exemplo, ao instalar diferentes versões de uma mesma DLL para atender a um novo aplicativo, podem ocorrer erros que impossibilitem o funcionamento de aplicativos que já estavam operantes, disponibilizando o acesso apenas a estes novos. Ou na pior das hipóteses, Conflitar aplicações diversas gerando o “caos”, com o alarde de que está fora do ar.

  • Dificuldade na integração com outros aplicativos:

Também existe o problema da falta de integração com outros aplicativos em uma mesma corporação. O fato é que algumas empresas criaram necessidades departamentais, portanto aplicações foram particularizadas, acessando individualmente dados diferentes. Sem a integração de aplicativos consolidada, um departamento reporta-se sobre alguma informação diferentemente de um segundo departamento. Daí surge a questão: Em qual informação confiar?

Modelo de Desenvolvimento em 3 Camadas

Motivado com crescimento da internet, a proposta do modelo de desenvolvimento em 2 camadas ganha novos aperfeiçoamentos, surgindo em sua evolução o modelo de desenvolvimento em 3 camadas. A mudança agora se estabelece de maneira em que as Regras de Negócio sejam retiradas da responsabilidade Cliente e transferidas a um servidor com a denominação de Servidor de Aplicações.

O Banco de Dados é acessado pelas regras de negócio contidas no Servidor de Aplicações, onde já nota-se um ganho na citada desvantagem Manutenção e Atualização, presente no modelo de desenvolvimento em 2 camadas. O resultado é a sequencia onde, para acessar o Banco de Dados, o Cliente deverá primeiro passar pelo Servidor de Aplicações.

Em síntese, neste modelo existem 3 camadas (como o próprio nome evidencia) com as seguintes funções:

Apresentação: permanece no Cliente (igualmente citado no modelo de desenvolvimento em 2 camadas), existindo ainda a necessidade de atualização em todas as máquinas caso ocorra alguma mudança que reflita na Interface do Usuário.

Lógica do Negócio: regras de negócios são estabelecidas nesta camada, a diferença é que no modelo em 3 camadas, a responsabilidade foi transferida para o Servidor de Aplicações (onde qualquer mudança de regra deva ser atualizada neste servidor) e não pertence mais ao Cliente. O ganho ocorre, pois atualizando a regra no Servidor de Aplicações (um único ponto), todos os Clientes sentirão o reflexo da modificação destas regras recebendo a versão mais atual.

Banco de Dados: acessado através do Servidor de Aplicação e não mais diretamente do Cliente, contém igualmente ao modelo em 2 camadas, as informações da aplicação.

Com o modelo de desenvolvimento em 3 camadas, a desvantagem de atualização levantada no modelo de desenvolvimento em 2 camadas com relação as regras de negócio foi resolvida, porém a manutenção na camada de Apresentação continua em herança de desvantagem do modelo anterior.

Modelo de Desenvolvimento em Camadas - Modelo de Arquitetura Cliente/Servidor - Modelo de Desenvolvimento em 3 camadas

Modelo de Arquitetura Cliente/Servidor – Modelo de Desenvolvimento em 3 camadas

Considerações Finais:

As considerações finais não se aplicam a este post. Na próxima publicação, segunda parte da série: Arquitetura em Camadas, será apresentado o modelo de Desenvolvimento em ‘n’ camadas.

Referências Bibliográficas:

As referências bibliográficas serão apresentadas no último post desta série.

Sobre o autor

Thiago Richard Vanicore

Thiago Richard Vanicore formou-se em análise e desenvolvimento de sistemas, possui certificação ITIL Foundation V2 e entre seus conhecimentos estão: ASP .Net (WebForms/MVC5/Web API) C#, HTML5, Html/XHtml, CSS3, JQuery, JQuey Mobile, JavaScript, Xml, Ajax, Json, Microsoft SqlServer, MySql, Firebird, Azure, Visual Studio Online, Scrum, UML, CRM, Quality Assurance, CTI (Computer Telephony Integration) MPSBR (Melhoria de Processos do Software Brasileiro).

Link permanente para este artigo: http://linksinergia.com.br/2014/07/16/arquitetura-em-camadas-parte-1-modelo-de-desenvolvimento-em-camadas/