4. As três camadas
principais
A lógica de apresentação
diz respeito a como tratar a interação
entre o usuário e o software. Isto pode
ser tão simples quanto uma linha de comando
ou um menu baseado em texto, ou pode ser uma
complexa interface gráfica do tipo cliente
rico (Delphi, VB, Swing, etc.) ou uma página
HTML. As responsabilidades primárias
da camada de apresentação são
exibir informações para o usuário
e traduzir comandos do usuário em ações
sobre a camada de domínio e a camada
de dados.
A lógica da camada de dados consiste,
na maioria das vezes, no armazenamento dos dados
persistentes da aplicação em um
banco de dados.
A lógica de domínio, também
chamada de lógica de negócio consiste
na inteligência da aplicação,
isto é, aquilo que os stakeholders esperam
que a aplicação faça. Ela
envolve cálculos baseados nas entradas
e em dados armazenados, validação
de quaisquer dados provenientes da camada de
apresentação e a compreensão
exata de qual lógica de dados executar,
dependendo dos comandos recebidos da apresentação.
Uma regra usualmente aceita sobre dependências
estabelece que a lógica de domínio
e a camada de dados não devem ser dependentes
da apresentação, isto é,
não deve haver chamadas de sub-rotinas
da apresentação a partir do código
do domínio ou da camada de dados. Esta
regra torna mais fácil utilizar apresentações
diferentes sobre a mesma base e torna mais fácil
modificar a apresentação sem ramificações
sérias mais abaixo. O relacionamento
entre o domínio e a camada de dados é
mais complexo e depende dos padrões arquiteturais
usados para a fonte de dados.
5) Organizando a Lógica de Domínio
Vamos apresentar duas maneiras distintas de
organizar a lógica do domínio:
Modelos de Domínio e Módulos Tabela.
5.1 Modelos de Domínio
A lógica complexa é o cenário
ideal para os objetos e a abordagem OO tradicional
para lidar com este problema é através
de um Modelo de Domínio. Neste padrão,
construímos um modelo do domínio
organizado em torno dos conceitos deste domínio.
Assim, um sistema para uma biblioteca teria
classes para o usuário, livros, exemplares,
empréstimos, devoluções,
multas, etc. Neste modelo, cada instância
de um conceito do domínio corresponde
a um objeto em memória. Assim, teríamos
um objeto livro para cada livro da biblioteca,
um objeto usuário para cada usuário
e assim por diante. As responsabilidades do
sistema são divididas entre as classes
do domínio de modo que, por exemplo,
um objeto exemplar pode ter um método
para determinar o usuário que está
de posse do livro.
O Modelo de Domínio, em oposição
à decomposição funcional,
é a essência da mudança
de paradigma de que a comunidade OO tanto fala.
Ao invés de uma única rotina contendo
toda a lógica para uma transação,
cada objeto é responsável por
realizar parte da lógica e a inteligência
da aplicação nasce dessa complexa
rede de colaboração entre objetos,
trocando mensagens dizendo uns aos outros o
que fazer.
A Figura 2 mostra um diagrama de seqüência
para o caso de uso “Localizar os Usuários
que detém os Livros” usando um
Modelo de Domínio.
O valor de um Modelo de Domínio reside
no fato de que existem muitas técnicas
que permitem lidar com lógica complexa
de uma forma bem organizada [Gamma et al.]
Os inconvenientes no uso de um Modelo de Domínio
vem da complexidade do uso e da complexidade
da camada de dados. Freqüentemente os desenvolvedores
precisam trabalhar por meses em projetos utilizando
este padrão antes que seus paradigmas
mudem. Mesmo depois da mudança de paradigma
ainda é preciso lidar com o mapeamento
dos objetos para um banco de dados relacional.
Quanto mais complexa sua lógica de domínio,
mais difícil é o mapeamento. Algumas
soluções Open Source estão
disponíveis para a persistência
de objetos em diversos ambientes (tiOPF para
Delphi, Hybernate e Prevayler para Java, etc.)
5.2 Módulos Tabela
Uma alternativa para estruturar a lógica
do domínio é o Módulo Tabela.
À primeira vista, o Módulo Tabela
se parece com o Modelo de Domínio, uma
vez que ambos têm classes para livros,
exemplares, usuários e empréstimos.
A diferença vital é que um Modelo
de Domínio tem uma instância de
exemplar para cada exemplar no banco de dados,
enquanto que um Módulo Tabela tem apenas
uma instância da classe exemplar.
A força do Módulo Tabela é
que ele permite encapsular dados e comportamento
em objetos e, ao mesmo tempo, tira proveito
do poder de um banco de dados relacional. Na
superfície, o Módulo Tabela se
parece muito com um objeto regular. A principal
diferença é que ele não
tem o conceito de identidade dos objetos com
os quais trabalha. Assim, se você quiser
obter o título de um livro, deve usar
um método como Livro.lerTitulo(int IDdoLivro).
Sempre que você quiser fazer algo com
um livro específico, tem que passar algum
tipo de identificação deste livro
para o Módulo Tabela correspondente.
Freqüentemente, esta será a chave
primária usada no banco de dados.
Um Módulo Tabela é uma solução
simples para organizar a lógica do domínio,
no entanto, você não pode usar
várias das técnicas que um Modelo
de Domínio usa para estruturar a lógica
em granularidade mais fina, tais como herança,
estratégias e outros padrões OO.
A Figura 3 mostra um diagrama de seqüência
para o caso de uso “Localizar os Usuários
que detém os Livros” usando Módulos
Tabela.
|
