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.
