Friday, June 29, 2012

Padrões EAA (Enterprise Application Architecture)



 O que significa EAA?

Enterprise Application Architecture é uma das técnicas mais comuns de desenvolvimento, onde as partes complexas da aplicação são desmembradas em camadas.

Apresenta como principais benefícios: isolamento, independência, reutilização de Código, desacoplamento  e fácil entendimento (código limpo e sucinto).

Os padrões EAA são muito comuns em softwares que envolvam grande volume de dados, acesso concorrente e integração com outros sistemas.
Exemplos:  Payroll, Supply Chain Management, ERP, etc...

As três camadas principais e mais encontradas nesses tipos de sistema são:
                Apresentação: Controla a interação entre o usuário e o software
                Domínio: Controla as regras de negócio do sistema.
                Fonte de Dados: Controla as comunicações com o banco de dados.




 Exemplos de Padrões EAA:

a)       Domain Logic

·         Transaction Script:
Organiza a lógica de negócios através de procedimentos onde cada procedimento trata de um request único da apresentação.
Por exemplo, se a precisamos matricular um aluno em uma determinada turma, a lógica para verificar quantidade de vagas na turma, requisitos do aluno, horários conflitantes com outras matérias do aluno e etc.. deve, estar compreendidas na mesma transação MatricularAluno(aluno, turma)

·         Table Module:
               Uma única instância que lida com a lógica de negócios para todas as linhas em uma tabela ou exibição de banco. Permite o empacotamento de dados e  a sua utilização deve se dar quando se deseja manipular dados tabulares usando um RecordSet.

·         Domain Model:
Um modelo do domínio que incorpora tanto o comportamento quanto os dados e contém os objetos que modelam a área de negócio.
Um modelo de domínio bem pensado serve como uma representação clara da estrutura conceitual do domínio do problema e, portanto, é imprescindível para garantir que todos os interessados estejam alinhados com escopo e significado.

b)       Service Layer

Camada de serviços que estabelece um conjunto de operações disponíveis e coordena a resposta da aplicação em cada operação.

O benefício da camada de serviço é que define um conjunto comum de operações, disponível para muitos tipos de clientes e coordena a resposta da aplicação em cada operação.
Na Arquitetura Orientada a Serviços (SOA), a camada de serviço é a terceira camada em um modelo de cinco camadas de abstração.

O modelo consiste em Object Layer, Component Layer, Service Layer, Process Layer e Enterprise Layer. [3] A camada de serviço pode ser considerada como uma ponte entre as camadas superior e inferior.



c)        Repository

Media as camadas de domínio e mapeamento de dados usando uma interface de coleção, para acessar objetos de domínio. Utilizado para atingir um ou mais dos seguintes objetivos:

·         Maximizar a quantidade de código que pode ser testada com  automação e isolar a camada de dados para suportar o teste de unidade.
·         Você pode acessar a fonte de dados de diversas localidades e deseja aplicar gerenciados centralmente, regras de acesso consistente e lógica.
·         Implementar e centralizar uma estratégia de cache para a fonte de dados.
·         Melhorar a manutenção do código e a legibilidade, separando a lógica de negócios a partir de dados ou lógica de acesso ao serviço.
·         Usar entidades empresariais que são fortemente tipadas para que você possa identificar os problemas em tempo de compilação em vez de em tempo de execução.
·         Associar um comportamento com os dados relacionados. Por exemplo, você deseja calcular campos ou impor relações complicadas ou de regras de negócios entre os elementos de dados dentro de uma entidade.
·         Você deseja aplicar um modelo de domínio para simplificar a lógica de negócios complexos.




d)       Active Record

Um objeto que envolve uma linha de tabela ou view, encapsula o acesso a banco de dados e adiciona lógica de domínio sobre esses dados.

A interface de um certo objeto deve incluir funções como por exemplo Inserir(Insert), Atualizar(Update), Apagar(Delete) e propriedades que correspondam de certa forma diretamente às colunas do banco de dados associado.

Uma instância de um objeto é amarrada a um único registo na tabela.  A classe de embrulho implementa os métodos de acesso(setter e getter) ou propriedades para cada coluna na tabela ou visão.
Este padrão é comumente utilizado por ferramentas de persistência de objetos e em mapeamento objeto-relacional. Geralmente as relações de chave estrangeira serão expostas como uma instância do objeto do tipo apropriado por meio de uma propriedade.

Implementações do conceito podem ser encontradas em vários Frameworks para diversos ambientes de programação. Por exemplo, se um banco de dados possui a tabela produtos e o padrão de projeto Active Record é implementado na classe Produto, o pseudo-código:

produto = new Produto()
produto.nome = "Produto exemplo"
produto.valor = 123.45
produto.save()

Irá criar um novo registro na table produtos com os valores fornecidos sendo grosseiramente equivalente ao comando SQL:

INSERT INTO produtos (nome, valor) VALUES ('Produto exemplo', 123.45);



e)       Unity of Work

Um dos padrões de design mais comuns em EAA, este padrão "mantém uma lista de objetos afetados por uma transação e coordena a escrita de alterações e a resolução dos problemas de concorrência.".

Este padrão aparece em quase todos os frameworks de persistência mais comuns no mercado de hoje. Por exemplo: a interface ITransaction em NHibernate, a classe DataContext no LINQ to SQL, e a classe ObjectContext no Entity Framework.

Se você fosse construir o seu próprio Unity of Work, seria provavelmente algo parecido com esta interface:
public interface IUnitOfWork {
  void MarkDirty(object entity);
  void MarkNew(object entity);
  void MarkDeleted(object entity);
  void Commit();
  void Rollback();
Sua classe deve conter métodos para marcar entidades como alteradas, novas ou excluídas e para confirmar ou reverter todas as mudanças.
De certa forma, você pode pensar no Unit of Work como um lugar para despejar todo o código de manipulação de transação.
As responsabilidades da Unidade de Trabalho são:
Gerenciar as transações.
Ordenar as inserções de banco de dados, exclusões e atualizações.
Impedir duplicação de atualizações.


No comments:

Post a Comment