Arquitetura de soluções e a organização de componentes.

Olá pessoal, tudo certo?

A semana segue com o assunto Arquitetura de Soluções, destacando como os componentes de software de sua solução estão organizados e interagem em tempo de execução. De forma histórica, todos lembramos do modelo de 3 camadas, muito utilizado por legados em VB6, Delphi, ASP WinDNA, entre outros. Quem não se lembra de desenhos como esse:

O modelo procurava separar funcionalidades em camadas, permitindo que alterações realizadas no camada de negócios tivessem o mínimo impacto na camada de apresentação e assim por diante. "Dividir para Conquistar" era o lema. Outros nomes frenquentes para essas camadas foram: Presentation Layer (PL), Business Logic Layer (BLL) e ainda Data Access Layer (DAL).

Uma evolução do modelo para arquiteturas distribuídas, contemplando passagens de parâmetros, disponibilidade de serviços, abstração do acesso a dados, etc.,
era dado pela figura a seguir:

No desenho ao lado, vemos a camada de apresentação (Presentation Tier), uma camada de processos de negócio (Business Process Components) e uma camada de acesso a dados.

Essa camada de acesso a dados apresenta 2 elementos básicos: o modelo de entidades de negócio (Business Entities) e o modelo de acesso a dados (Data Access Logic Componentes).

Como recursos de toda a estrutura encontramos nosso repositório de dados da aplicação (Application Data).

Se você olhou para esses desenhos e reconheceu suas aplicações, muito bom! É bem provável que sua solução seja capaz de migrar sem muitas dores para outros modelos de arquitetura ou plataformas.

Se os desenhos foram novidades, ops! ...o gato subiu no telhado... :) 

Mais recentemente, você deve ter ouvido falar em orientação a serviços, interfaces de serviços ou mesmo conceitos de serviços encapsulando regras de negócio. Do mesmo modo, orquestração de processos via workflows tem sido uma alternativa presente em algumas soluções. Software + Services e consumo de serviços online são outras tendências também disponíveis para nossos sistemas.

De fato, existem várias abordagens para uma arquitetura de solução, que ainda deve considerar questões importantes como tratamento de exceção, configuração, monitoração, segurança e controle de acesso, logging e instrumentação, transação, etc. De acordo com o foco da arquitetura, iremos representar cada um desses temas em camadas diferentes, realizando simplificações no modelo.

Independente da abordagem adotada, a definição de uma arquitetura é um fator crítico para a construção de uma solução de sucesso. Em posts futuros, vamos discutir algumas abordagens de arquiteturas, já contemplando as novas tecnologias da plataforma Microsoft, como Entity Framework, LINQ, Velocity, Data Services, WCF, Dynamic Data, etc.

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments

• Anonymous
  September 16, 2008
  Ola estou estudando sobre arquitetura 3 camadas ... e tem um professor de faculdade que me deixou entrigado!!! EX: tenho as seguintes camadas... Camada Apresentacao Camada Negocio     - Fachada Camada Dado     - Objetos (existe a Classe Pessoa)     - Crud Obs: o prof disse que não posso carregar o objeto Pessoa apartir da apresentação!!! disse que tenho que a carregar apartir da camada negoccio??? :( ou seja, tenho que passar por parametro ???       Ex: Pessoa oPessoa = new Pessoa();           oPessoa.Nome = txtNome.Text;           Sistema.Negocio.Fachada.Instancia.Salvar(oPessoa); essa é minha dúvida??

• Anonymous
  September 17, 2008
  Olá Leonel, De fato, quando organizamos uma arquitetura em camadas, o principal objetivo é isolar responsabilidades entre os componentes da solução. No modelo tradicional de 3 camadas, a camada de apresentação é responsável pelo tratamento de eventos e comportamentos da interface, recebendo parâmetros e valores que serão apresentados para o usuário. A camada de negócio é responsável pela manipulação dos dados ou aplicação de regras de negócio, implementando os casos de usos e processos que fundamentam as funcionalidades da aplicação. Finalmente, a camada de dados é responsável pelo mapeamento de entidades e bancos de dados previstos, permitindo o acesso aos bancos da aplicação. Assim, surge a necessidade de passagens de parâmetros entre as camadas, com certeza. Em algunas casos, o número de parâmetros e transferências de dados entre as camadas pode ser tão complexo que provoca a chamada "explosão de tipos', quando criamos diferentes tipos para cada manipulação de dados na aplicação. Sobre isso, veja o artigo do arquiteto Otávio Coelho abaixo, que comenta sobre o assunto: O mapeamento entre dados relacionais e objetos (ou: “OO or not OO? That is the question”) Ref.: http://msdn.microsoft.com/pt-br/library/cc580623.aspx Mais recentemente, temos a visão de serviços e interfaces de serviços que isolam os componentes de negócio da camada de apresentação. Através dessas fachadas, também é possível exportar serviços para outros sistemas, considerando questões como autenticação, autorização, controle de acesso, etc, já embutidos na própria fachada. Mas veja que em algum momento, você terá o desafio de serializar e deserializar dados e entidades que serão trafegados entre camadas. Para exemplificar uma discussão sobre passagem de parâmetros complexos entre diferentes camadas, veja o post abaixo: Using WCF, JSON, LINQ, and AJAX: Passing Complex Types to WCF Services with JSON Encoding Ref.: http://blogs.msdn.com/kaevans/archive/2007/09/04/using-wcf-json-linq-and-ajax-passing-complex-types-to-wcf-services-with-json-encoding.aspx Assim, vale a pena estudar o tema. Seu professor tem razão! :) Um abraço! Waldemir.