1. Curso: Tecnologia em Análise e Desenvolvimento de
Sistemas
Disciplina: Arquitetura de Software
Prof. Msc. Petrônio Candido Lima e Silva
Dupla: Aline Ferreira e Aricelio de Souza
Turma: 5º Periodo
2. Catálogo de Design Patterns
P of EAA – Martin Fowler
Introdução ao catálogo Pof EA.
. Lazy Load. . Service Layer.
. Separated Interface. . Referências.
. Value Object.
. Query Object.
. Repository.
. Identity Map.
. Unity of Work.
. Active Record.
3. Introdução ao Catálogo
P of EAA
O livro Patterns of Enterprise
Application Architecture começou a ser
desenvolvido depois de Davi Rice e
Martin Fowler terem dado palestras
sobre arquitetura J2EE e refletido sobre
como os conceitos que haviam
aprendido foram cruciais para o
desenvolvimento de seus projetos.
4.
O livro tem o propósito de definir
padrões de projeto para ajudar
desenvolvedores, indepentente da
plataforma que utilizam.
O livro é dividido em duas partes:
1ª parte: Tutorial sobre arquitetura de
aplicações corporativas.
2ª parte: Referência para cerca de 40
tipos de padrões de projeto.
Para cada padrão é descrito como
funciona e quando usá-lo, com
exemplos em Java, C# ou ambos.
Introdução
5. Lazy Load
Lazy Load
Finalidade
O Lazy Load tem a finalidade de
interromper o processo de carregamento
de objetos que não serão usados.
Ele coloca um marcador na estrutura dos
objetos de modo que se os dados forem
necessários à aplicação serão
carregados apenas quando forem
usados.
6. Lazy Load
Como é implementado?
Inicialização Tardia (Lazy Inicialization).
Proxy Virtual (Virtual Proxy).
Armazenador de Valor (Value Holder).
Fantasma (Ghost).
7. Lazy Load
Inicialização Tardia (Lazy
Inicialization)
Abordagem mais simples.
Consiste em verificar se um campo é nulo
antes de acessá-lo. Sendo nulo, ele calcula
o valor do campo antes de retornar o
mesmo.
Para que fucione, o campo a ser lido deve
estar auto-encapsulado.
9. Lazy Load
Proxy Virtual (Virtual Proxy)
É um objeto que parece com o objeto que
deveria estar no campo, mas não contém
nada.
Somente quando um dos seus métodos é
chamado, ele carrega o objeto correto a
partir do banco de dados.
11. Lazy Load
Armazenador de Valor (Value
Holder)
É um objeto que encapsula algum outro
objeto.
Para obter o objeto subjacente, você
solicita seu valor ao armazenador de valor.
Sua desvantagem é que a classe precisa
saber que ele existe.
14. Lazy Load
Fantasma (Ghost)
É o objeto real em um estado parcial. Ao ser
carregado do banco de dados, ele contém apenas
seu ID.
Sempre que o acesso a um campo for solicitado, ele
carrega seu estado completo.
Um fantasma é um objeto, onde cada campo é
inicializado tardiamente.
O objeto é carregado de forma incompleta, porém
com seu identificador (chave) e carrega seus dados
no primeiro acesso a suas propriedades.
16. Separated Interface
Define uma interface para desacoplar
uma camada de outra. As vezes é preciso
contradizer a regra de dependencia entre
camadas, por exemplo, uma camada
acessar outra sem passar pelas
intermediarias ou uma camada não
depender de outra.
Separated Interface
17.
Para por exemplo, a camada de
apresentação acessar a camada de
pesistência diretamente, a apresentação
passaria a depender da interface da
camada de pesistência.
Assim, mesmo que as classe da camada
de pesistência mudem, se a interface não
mudar, a apresentação não precisará
mudar.
Separated Interface
21. Value Object
Em diversas aplicações orientadas a
objetos, muitos objetos possuem uma
Identidade.
Uma importante classe de domínio como
a classe Cliente terá vários atributos. O
valor desse atributos é que diferenciam
diferentes objetos de sua classe.
Portanto, um objeto com uma Identidade,
PERSISTE, ou seja, ele existe durante
toda aplicação.
Value Object
22. Value Object
Value Object
Mas existem situações em que alguns
objetos NÃO precisam ter uma
Identidade, pois esses objetos
representam apenas características
singulares de outros objetos.
Exemplos: Classe Dinheiro, Data, etc.
Esses objetos não precisam de uma
identidade, pois representam somente
valores, ou seja, eles não precisam
persistir durante toda a aplicação.
23.
24.
25. Query Object
Segundo FOWLER (2006), Query Object é
uma especialização do padrão Interpreter
que constroi frases de consulta SQL com
base em uma estrutura de objetos.
O padrão propõe que se utilize um objeto
para conter todos os parametros
necessários a construir a consulta SQL.
Um objeto que representa uma consulta
ao banco de dados.
Query Object
30. Identity Map
Segundo FOWLER (2006), esse padrão
assegura que cada objeto seja carregado
apenas uma vez, mantendo cada objeto
carregado em um mapa. Assim, ele
procura os objetos usando o mapa quando
se referindo a eles.
Um identity map mantém um registro de
todos os objetos que foram lidos do banco
de dados em uma única transação de
negócio.
Identity Map
31. Identity Map
Sempre que quiser um objeto, você
verifica o Mapa de identidade antes para
ver se já o tem, semelhante a um cache.
Identity Map explicito: É acessado com
métodos distintos para cada tipo de objeto
que é preciso.
Identity Map genérico: Usa um único
método para todos os tipos de objetos.
Identity Map
33. Active Record
O padrão Active Record encapsula a
lógica para se criar uma linha na tabela
correspondente a respectiva classe.
Onde,cada objeto sabe como ler e gravar
seus dados no banco de dados, não existe
uma camada específica para realizar essa
tarefa.
Active Record
34.
Este tipo de estrutura é indicada para
sistemas menores onde a lógica de
dominio não é tão complexa, como
inserções,exclusões etc..
A estrutura dos dados dos objetos do
Active Record devem ser exatamente
iguais com a estrutura dos dados no
Banco de Dados, o que dificulta a
manutenção em razão da dependência
entre os mesmos.
Active Record
38. Repository
O padrão Repository faz a mediação
entre o domain model e as camadas de
mapeamento de dados, agindo como uma
coleção de objetos de domínio em
memória FOWLER (2006).
Esta camada abstrai o acesso a camada
de persistência, isolando a lógica de
acesso aos dados de qualquer outra
camada da aplicação.
Repository
39.
Este padrão é indicado para o
desenvolvimento de aplicações que
possuem um grande número de classes e
nescessitam de consultas mais pesadas,
além de ajudar a minimizar as duplicações
nas lógicas das consultas.
Repository
42. Unity of Work
Mantém uma lista de objetos afetados por
uma transação de negócio e coordena a
gravação das alterações e a desolução de
problemas de concorrência FOWLER (2006).
Unity of Work
43. Unity of Work
Uma Unit of work pode ser entendida como
uma sessão ou objeto que mantém o registro
de todas as atividades relacionadas ao banco
de dados, realizadas durante uma transação
de negócio, sendo também responsável pelo
gerenciamento dos problemas de
concorrência que podem ocorrer oriundos
dessa transação.
Unity of Work
44. Unity of Work
É indicada para situações onde são
necessários:
Efetuar logs.
Tracing.
Gerenciar as transações.
Promover a testabilidade dos sistema, etc.
Unity of Work
47. Service Layer
Define os limites de uma aplicação com uma
camada de serviços que estabelece um
conjunto de operações disponíveis e
coordena a resposta da aplicação em cada
operação.
Uma Camada de Serviço define a fronteira de
uma aplicação e seu conjunto de operações
disponiveis, a partir da perspectiva das
camadas de interface dos clientes.
Service layer
48. Service Layer
Ela encapsula a lógica de negócio da
aplicação, controlando as transações e
coordenando as respostas na implementação
de suas operações.
Service layer
52. Referências
ALMEIDA, Erico Renato Oliveira, Padrões de Projeto – Value
Object. 2007. Disponivel em:
<http://imasters.com.br/artigo/7293/linguagens/padroes-de-
projeto-value-object/>. Acesso em: 16 Mar 2014.
FOWLER, Martin. Padrões de Arquitetura de Aplicações
Corporativas / Martin Fowler; tradução Acauan Fernandes. -
Porto Alegre : Bookman, 2006.
PIRES, Glauber Magalhães. Lazy Loading – Inicialização
Preguiçosa. Disponivel em:
<http://www.glauberpires.com.br/arquitetura/4-Lazy
%20Loading.pdf>. Acesso em: 16 Mar 2014.
RANIERI, Bárbara. Lazy Load – Quando usar?. 2013. Disponivel
em: <http://www.princiweb.com.br/blog/programacao/aspnet/lazy-
load-quando-usar.html>. Acesso em: 16 Mar 2014.
Referências
53. SANTOS, Jadson José. Análise da Utilização de padrões no
Desenvolvimento de Software em Camadas. 2008. Disponivel
em: <http://jadsonjs.files.wordpress.com/2008/03/artigo-padroes-
de-projeto-padroes-basicos.pdf>. Acesso em: 16 Mar 2014.
TABORDA, Sérgio, Query Object. 2009. Disponivel em:
<http://sergiotaborda.wordpress.com/desenvolvimento-de-
software/java/patterns/query-object/>. Acesso em: 16 Mar 2014.
Referências