Arquitetura de Camadas em Java EE - Maraton4Java 2005

www.fragmental.com.br

Arquitetura de Camadas em Java™ Enterprise Edition™

Phillip Calçado

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...)


• Orientação a Objetos, Java™, Java EE™, Web... o de sempre!

Pré-Requisitos(Pentium IV, 512 MB RAM DDR,...)


• 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?)


• 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ê?


O que são Camadas(Por que esse povo de Java fala tanto em camadas?)


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?)


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?)


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


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


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

• ...


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


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


Camadas Lógicas em Java EE™ - Exemplos(Em VB não tem essas frescuras...)


• 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)


• 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)


•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


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


Camada de Apresentação: Alternativas(Ah, enfim algo produtivo...)

Smart UI: A GUI que Sabe o que Faz


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


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


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


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


Camada de Aplicação: Alternativas(Não julgue um livro pela capa)

Façade: Tudo na Interface


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


Camada de Aplicação: Alternativas(Back to the future)

Commands: A Herança


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


Camada de Negócios(Let the Show begin!)

• Chamada também de Camada de Domínio• Modela o domínio do problema• É o sistema!


Camada de Negócios: Alternativas(Já vi esse filme antes...)

Transaction Script: Quase um Command


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


Camada de Negócios: Alternativas(Orientação a Objetos é sobre o que mesmo?)

Domain Model: Como no Livro


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


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


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


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


Camada de Persistência: Alternativas(Se era mais fácil usar um banco OO? NÃO!)

Data Mapper: Ei, alguém sabe fazer isto!


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!


Camada de Persistência: Alternativas(Não era mais fácil usar um banco OO?)

Active Mapped Record: O Melhor dos Dois Mundos


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


• 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!)


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


• 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


GUJ - Fórum de Design


Contato

http://www.fragmental.com.br

http://www.riojug.org

http://www.guj.com.br

[email protected]


Obrigado!Que Zahl os Acompanhe...

Arquitetura de Camadas em Java EE - Maraton4Java 2005

Technology

Transcript of Arquitetura de Camadas em Java EE - Maraton4Java 2005