arquitetura de camadas em java ee - maraton4java 2005
DESCRIPTION
Palestra sobre arquitetura de camadas em Java para o Maratona4Java de Brasília.Slides em PDF disponíveis. Essa palestra originou o artigo Arquitetura de Camadas em Java EE publicado na revista Mundo Java número 15. Apresentada em 19/11/2005. http://blog.fragmental.com.br/wiki/index.php/Maratona4Java2005:_Arquitetura_de_Camadas_em_Java%E2%84%A2_Enterprise_EditionTRANSCRIPT
www.fragmental.com.br Slide 2
• Descrever e conceituar Arquitetura de Camadas em JEE™
• Apresentar e discutir técnicas para criação e integração destas
• Se divertir no processo
Objetivos
Não São Objetivos
• Mudar as suas convicções, sua cabeça, sua religião, seu time de futebol...
(Tentar dominar o mundo!)
(Droga! Sabia que devia ter ido pro bar...)
www.fragmental.com.br Slide 3
• Orientação a Objetos, Java™, Java EE™, Web... o de sempre!
Pré-Requisitos(Pentium IV, 512 MB RAM DDR,...)
www.fragmental.com.br Slide 4
• Quem é Você?• O que são Camadas• Camadas Físicas• Camadas Lógicas• Camadas em Java™ EE™• Integração entre Camadas: Boas Praticas• Integração entre Camadas: Más Praticas• Camada de Apresentação: Alternativas• Camada de Aplicação: Alternativas• Camada de Negócios: Alternativas• Camada de Persistência: Alternativas• Conclusão
Agenda(A gente veio aqui pra beber ou conversar?)
www.fragmental.com.br Slide 5
• Phillip Calçado, a.k.a. Shoes• Programador desde 1996• Com Java desde 2003 (“¡ adios, C++ !”)• Coordenador do GUJ• JUG Leader do RioJUG• Consultor, instrutor, coach• Diversos projetos open-source (alguns chegaram até a
ter uma versão 1.0!)• Escritor ocasional (http://www.fragmental.com.br)• Aplicações para análise de risco, redes GSM, gestão de
conteúdo, setor financeiro, biologia... A grande maioria utilizando Java EE
Quem é Você?
www.fragmental.com.br Slide 7
O que são Camadas
• Divisão Lógica de componentes de software(layer) ou hardware(tier)
• Separam componentes por responsabilidade comum
• Se comunicam de cima para baixo (quase sempre)
• Camadas Famosas:– TCP/IP– Sistemas Operacionais– Java– .Net
(Por que esse povo de Java fala tanto em camadas?)
www.fragmental.com.br Slide 8
O que são Camadas
Algumas Vantagens:• Reduzem complexidade• Reduzem dependência /
acoplamento• Favorecem a coesão• Promovem reusabilidade• São um Padrão
conhecidoAlgumas Desvantagens• Limitadas pela tecnologia• Não existe um mercado
de COTS• Apenas complicam um
sistema muito simples• Arquitetos
megalomaníacos adoram
(Por que esse povo de Java fala tanto em camadas?)
www.fragmental.com.br Slide 9
Camadas Físicas(Das geladeiras pretas aos celulares)
• Formada por nós que se comunicam• Um nó nesse contexto é uma unidade de
processamento:– JVM– Servidor– Computador Pessoal– Servidor de Aplicações– CPU
www.fragmental.com.br Slide 10
Camadas Físicas - Evolução(Das geladeiras pretas aos celulares)
• Fase 1: Mainframes– Tudo no mesmo nó
• Fase 2: Cliente/Servidor– Banco de dados separado– Interface separada– Regra de negócios acoplada com Interface ou Banco de
Dados
• Fase 3: 3-Tier– Um nó para persistência, um para Negócios e um ou mais
para interface
• Fase 4: n-Tier– Um nó por conceito
www.fragmental.com.br Slide 11
Camadas Lógicas(“Ah, as famosas tres camadas. Massa, recheio e cobertura. A culinaria francesa em geral me decepciona, mas as sobremesas sao sempre otimas. “ – Carlos Villela - GUJ )
• 2, 3, 4 ou N Camadas? • Camada de Apresentação
é a Interface• Camada de Aplicação
coordena casos de uso• Camada de Negócios é
onde fica a Lógica de negócios
• Camada de Persistência são os componentes que salvam o estado do objeto em algum lugar
• ...
www.fragmental.com.br Slide 12
Camadas Lógicas - Evolução(“Ah, as famosas três camadas. Massa, recheio e cobertura. A culinária francesa em geral me decepciona, mas as sobremesas são sempre ótimas. – Carlos Villela - GUJ)
• Sistemas Operacionais– I/O– Gerência de memória
• Bancos de Dados– Gerência dos Dados
• Interfaces de Usuário– Independência de Interface– Paradigma Web/HTTP
• Middleware– RPC
– Mensagens• Regras de Negócio
– Funcional– OO
www.fragmental.com.br Slide 13
Camadas Físicas em Java EE™(O pecado original)
• Java EE pressupõe sistemas altamente distribuídos• EJBs foram criados para ambientes altamente
distribuídos• Design Patterns Java EE™ são gambiarras para sistemas
altamente distribuídos• Mas...
A maioria esmagadora dos sistemas construídos
usando Java™ EE™ não são e nunca serão altamente
distribuídos
www.fragmental.com.br Slide 14
Camadas Lógicas em Java EE™ - Exemplos(Em VB não tem essas frescuras...)
www.fragmental.com.br Slide 15
• Camadas deveriam ser empilhadas, mais básicas abaixo, mais especificas acima
• Dependência é sempre de cima para baixo
• Utilize Depedency Injection para integrar Camadas
• Camadas escondem as inferiores das superiores
• A camada de cima conhece a interface da inferior, nunca sua implementação
Integração entre Camadas: Boas Praticas(Ou: Não Fale com Estranhos)
www.fragmental.com.br Slide 16
• Golden Hammer: Camadas para Tudo e Todos• Queimando Etapas: Interface conecta com
Persistência• Decomposição Funcional: Commands como Funções• Gordura Extra: Não expor operações de baixa
granularidade• Despachante: Camada transparente que não faz
nada• Mochileiro das Galáxias: Objeto vai do fundo ao
topo das camadas,ou vice-versa• Data Transfer Objects (DTO/VO/TO): entre
camadas em mesmo nó
Integração entre Camadas: Más Praticas(Como perder dinheiro fácil)
www.fragmental.com.br Slide 17
•DTOs foram criados para reduzir custo de chamadas RPC•Padrão VO/TO é para vencer os problemas dos Entity Beans•Não faz sentido dentro do mesmo nó•Provoca hierarquia de classes duplicada•Não faz sentido com Lazy-Loading•Pode fazer algum sentido para encapsular Camadas
Integração entre Camadas: Más Praticas(Quando a Sun vai atualizar aqueles diagramas?)
Convidado Especial: DTOs Locais
www.fragmental.com.br Slide 18
Camada de Apresentação(Do laod que se vê)
• Interação entre usuário/subsistema e sistema• Pode ser gráfica, textual, XML, CSV...• Responde a estímulos do usuário e exibe seus resultados• Não contêm Lógica de Negócios
www.fragmental.com.br Slide 19
Camada de Apresentação: Alternativas(Ah, enfim algo produtivo...)
Smart UI: A GUI que Sabe o que Faz
www.fragmental.com.br Slide 20
Camada de Apresentação: Alternativas(Ah, enfim algo produtivo...)
• Chamadas à interface realizam regras de negócio• Alta produtividade• Muito comum em Delphi/VB e demais• Desenvolvedores menos experiente se sentem
confortáveis• Ferramentas RAD ajudam bastante
• Código repetido aos montes• Alto acoplamento e baixa coesão• Programação Orientada a Telas, não a Objetos• Incompatível com um Domain Model• Integração entre aplicações extremamente complicada
Smart UI: A GUI que Sabe o que Faz
www.fragmental.com.br Slide 21
Camada de Apresentação: Alternativas(Toda vez que voce usa Struts, Deus mata um bebe foca. Pense nas pobres foquinhas,
e parem de usar esse lixo. Por favooooooooooooooooooor. – Carlos Villela – GUJ)MVC: Subcamadas
www.fragmental.com.br Slide 22
Camada de Apresentação: Alternativas(Toda vez que voce usa Struts, Deus mata um bebe foca. Pense nas pobres foquinhas,
e parem de usar esse lixo. Por favooooooooooooooooooor. – Carlos Villela – GUJ)
• Apresentação dividida entre View e Controller• Separação de responsabilidades• Vários e vários frameworks e ferramentas
• MVC para web não é MVC, é Front Controller• Costuma-se confundir MVC com Camadas• Modelo não é Persistência
MVC: Subcamadas
www.fragmental.com.br Slide 23
Camada de Aplicação(Alguém tem que controlar essa bagunça!)
• Coordena Casos de Uso• Controla como os Objetos de Negócio são utilizados• Muitas vezes é diluída entre Camada de Apresentação e
Camada de Negócios
www.fragmental.com.br Slide 24
Camada de Aplicação: Alternativas(Não julgue um livro pela capa)
Façade: Tudo na Interface
www.fragmental.com.br Slide 25
Camada de Aplicação: Alternativas(Não julgue um livro pela capa)
• Expõe conceitos, não implementação• Controla bem Casos de Uso• Garante consistência: só é possível entrar o que foi
planejado
• Limita uso de Camada de Negócios• Pouca reusabilidade: e o que não foi previsto?
Façade: Tudo na Interface
www.fragmental.com.br Slide 26
Camada de Aplicação: Alternativas(Back to the future)
Commands: A Herança
www.fragmental.com.br Slide 27
Camada de Aplicação: Alternativas(Back to the future)
• Fácil de entender• Atômico• Se não formalizada uma Camada de Aplicação,
facilmente implementado com MVC
• Programação altamente Procedural• Explosão de Commands e baixíssima reusabilidade• Camada de Aplicação não é limitada a Request/Response
Commands: A Herança
www.fragmental.com.br Slide 28
Camada de Negócios(Let the Show begin!)
• Chamada também de Camada de Domínio• Modela o domínio do problema• É o sistema!
www.fragmental.com.br Slide 29
Camada de Negócios: Alternativas(Já vi esse filme antes...)
Transaction Script: Quase um Command
www.fragmental.com.br Slide 30
Camada de Negócios: Alternativas(Já vi esse filme antes...)
• Simples• Rápido
• Não recomendado para lógica de negócios que não seja só tira-e-põe do banco de dados
• Programação Procedural sem objetos inteligentes• Incompatível com um Domain Model• Repetição de código• Baixa Reusabilidade
Transaction Script: Quase um Command
www.fragmental.com.br Slide 31
Camada de Negócios: Alternativas(Orientação a Objetos é sobre o que mesmo?)
Domain Model: Como no Livro
www.fragmental.com.br Slide 32
Camada de Negócios: Alternativas(Orientação a Objetos é sobre o que mesmo?)
• Melhor maneira de modelar problemas em OOP• Eficaz para Lógica Complexa• Altamente Orientado a Objetos
• Complexo demais para cosias muito simples• Baixa produtividade: programadores não estão
acostumados• Tecnologia limita seu uso
Domain Model: Como no Livro
www.fragmental.com.br Slide 33
Camada de Persistência(Como assim?)
• Responsável por armazenar objetos• Não prevista num modelo puramente OO, objetos seriam
eternos• Geralmente utiliza SGBDR, o que complica seu uso
www.fragmental.com.br Slide 34
Camada de Persistência: Alternativas(“Objetos são tabelas que acham que são gente...” - DBA Anônimo)
Active Record: Não dá para Esquecer
www.fragmental.com.br Slide 35
Camada de Persistência: Alternativas(“Objetos são tabelas que acham que são gente...” - DBA Anônimo)
• Simples• Rápido
• Quebra completamente camadas• Sem semântica: objeto é seu próprio repositório• Ruim para atualizações em lote
Active Record: Não dá para Esquecer
www.fragmental.com.br Slide 36
Camada de Persistência: Alternativas(Se era mais fácil usar um banco OO? NÃO!)
Data Mapper: Ei, alguém sabe fazer isto!
www.fragmental.com.br Slide 37
Camada de Persistência: Alternativas(Se era mais fácil usar um banco OO? NÃO!)
• Simples• Rápido• Mantêm Objetos de Negócio ignorantes sobre
persistência• Facilita testes podendo ser substituído
• Um passo “artificial” a mais em qualquer execução• Quando persistir?• Explosão de Classes• Sem um bom framework pode ser improdutivo• Sem lazy-loading fica complexo
Data Mapper: Ei, alguém sabe fazer isto!
www.fragmental.com.br Slide 38
Camada de Persistência: Alternativas(Não era mais fácil usar um banco OO?)
Active Mapped Record: O Melhor dos Dois Mundos
www.fragmental.com.br Slide 39
Camada de Persistência: Alternativas(Não era mais fácil usar um banco OO?)
• Simples• Rápido• Pode ser obtido com superclasses ou AOP• Não quebra Camadas• Não tem problema de “quando persistir?”
• Objetos precisam (uma hora ou outra) saber que não são persistidos automaticamente
• Não elimina Repositórios nem DAOs• Não funciona para grandes volumes de dados• Pode gerar inconsistência se o cliente não salvar o objeto• Experimental
Active Mapped Record: O Melhor dos Dois Mundos
www.fragmental.com.br Slide 40
• Não Compensa em:• Aplicações simples que não fazem mais que tirar e
colocar registros no banco• Protótipos• Partes da Aplicação com Relatórios Pesados
• Possíveis Soluções Menos Problemáticas:• Groovy / BeanShell / Jython / jRuby• Ruby on Rails/ PHP• Shell Scripts / Ruby / Python / PERL• Ferramentas do SGBD• Ferramentas RAD
Quando Não Usar Camadas(Canhões, moscas...ah, você sabe!)
www.fragmental.com.br Slide 41
Conclusão
• Camadas != MVC• Na grande maioria das vezes, DTOs são inúteis• Não existe “a maneira certa”, existe “a mais adequada”
e esta varia com os requisitos• Flexibilidade é importante mas complexidade reduzida
também (talvez mais)• A tecnologia ainda é fator limitante para o
desenvolvimento OO
www.fragmental.com.br Slide 42
• Craig Larman – Applying UML and Patterns• Eric Evans – Domain-Driven Design• Bertrand Meyer – Object-Oriented Software
Construction• Martin Fowler – Refactoring, PEAI, Analysis Patterns...• Rod Johnson – J2EE Development Without EJB• Bruce Tate & Justin Gehtland – Better, Faster,
Lighter Java• Meilir Page-Jones – Fundamentals of Object-Oriented
Design Using UML• Andrew Hunt & David Thomas – The Pragmatic
Programmer
Autores Recomendados
www.fragmental.com.br Slide 44
Contato
http://www.fragmental.com.br
http://www.riojug.org
http://www.guj.com.br