Evitando Anemic Domain Model na pratica com JSF+Spring+JPA

JavaChild Membro desde: 23/08/2006 11:07:21 Mensagens: 130 Offline

Ae pessoal,

Lendo alguns artigos sobre Anemic Domain Model (ate mesmo um post há um tempo atrás) revi bastante meus conceito de OO e a maneira procedural que programava encorajado pela arquitetura J2EE 2.1. Agora gostaria de montar um sistema OO com JSF+Spring(podendo virar um EJB)+JPA e esbarrei em algumas dificuldades.
Li artigos sobre JSF+Spring+JPA(artigos abaixo) e olhando o livro Pojo in Action e ainda continuo com algumas duvidas
O JSF e os Managed Beans seriam para chamar as fachadas onde seria feita a parte transacional com Spring/EJB que essa fachada ordenaria as chamadas dos servicos, desatacharia os objetos e retornavam DTO para a camada JSF (esse é o melhor maneira mesmo?). Assim ficaria independente a camada de apresentacao da Fachada.
Outra duvida é na parte de modelo de dominio, com JPA seria correto eu mapear as classes de modelo de dominio adicionando numa classe Cliente os metodos update(), delete() e etc? Tendo assim uma classe ClienteRepository na qual teria metodos como find() e create()?
E a minha principal dúvida seria no Managed Bean, eu ter que passar para a fachada uma classe "Cliente" por exemplo, que creio que nao deveria ser conhecida pela camada de apresentacao, estou correto?
Aqui tem uma galera que discute legal sobre esses assuntos pelo que vi, varios posts sobre isso do pcalcado, Urubatan, Paulo Silveira, e mais uns outro....

Agradeco qualquer ajuda,
[]'s
Fernando

http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html
https://blueprints.dev.java.net/bpcatalog/ee5/persistence/facade.html
http://www.oracle.com/technology/products/ias/toplink/jpa/tutorials/jsf-jpa-tutorial.html

Ola Fernando

Minhas rapidas sugestoes:
- Nao ha motivo nenhum de usar DTO nesse caso: voce nao precisa tranferir dados entre tiers diferentes. Ele vai dificultar sua vida pra caramba: nao vai ajduar muito usar lazy loading, vai ter de copiar atributos com magicas, etc... alem de criar uma classe identica a sua entity... E mesmo que voce va usar EJB, pode usar a propria entidade fazendo appel de DTO, ja que fora do servidor de aplicacao ela esta "detached".
- Se voce vai usar EJB3, nao precisa de ClientRepository: seus session beans farão esse acesso a JPA. Se for usar JPA standalone, é legal sim fazer um façade. Chamar o manager de qualquer lugar é macarronico

Va com cuidado com os blueprints da sun: ela considera que voce esta trabalhando num mega projeto, cheio de tiers e layers, e que voce precisa de independencia e abstracao maxima de tudo!

Foram esses blueprints os responsaveis pela proliferacao de BOs, TOs, VOs e DTOs que assombram ate mesmo os menores projetos do mundo....

Tente simplificar sua arquitetura, itnerfacei os objetos, ai quando voce precisar voce vai ter a flexibilidade necessaria, sem ter de criar algo gigante desde o inicio.

JavaChild Membro desde: 23/08/2006 11:07:21 Mensagens: 130 Offline

- Nao ha motivo nenhum de usar DTO nesse caso: voce nao precisa tranferir dados entre tiers diferentes. Ele vai dificultar sua vida pra caramba: nao vai ajduar muito usar lazy loading, vai ter de copiar atributos com magicas, etc... alem de criar uma classe identica a sua entity... E mesmo que voce va usar EJB, pode usar a propria entidade fazendo appel de DTO, ja que fora do servidor de aplicacao ela esta "detached".

A ideia era o sistema poder funcionar em diferentes maquinas mesmo, como uma maquina com um servidor web, e uma maquina de aplicacao, por isso montada essa arquitetura, prevendo essa possibilidade, mas com certeza vai ser excessao, e acho que voce tem total razao no trabalho a mais que vai ser feito (e talvez nem usado)

- Se voce vai usar EJB3, nao precisa de ClientRepository: seus session beans farão esse acesso a JPA. Se for usar JPA standalone, é legal sim fazer um façade. Chamar o manager de qualquer lugar é macarronico

A JPA pode ou nao ser standalone, mas uma faćada controlando uma transacao (Session Facade ou via AOP do Spring) vai ser bem interessante

Post 24/05/2007 20:43:26 Assunto: Re:Evitando Anemic Domain Model na pratica com JSF+Spring+JPA
Ola Fernando

Minhas rapidas sugestoes:
- Nao ha motivo nenhum de usar DTO nesse caso: voce nao precisa tranferir dados entre tiers diferentes. Ele vai dificultar sua vida pra caramba: nao vai ajduar muito usar lazy loading, vai ter de copiar atributos com magicas, etc... alem de criar uma classe identica a sua entity... E mesmo que voce va usar EJB, pode usar a propria entidade fazendo appel de DTO, ja que fora do servidor de aplicacao ela esta "detached".
- Se voce vai usar EJB3, nao precisa de ClientRepository: seus session beans farão esse acesso a JPA. Se for usar JPA standalone, é legal sim fazer um façade. Chamar o manager de qualquer lugar é macarronico

Va com cuidado com os blueprints da sun: ela considera que voce esta trabalhando num mega projeto, cheio de tiers e layers, e que voce precisa de independencia e abstracao maxima de tudo!

Foram esses blueprints os responsaveis pela proliferacao de BOs, TOs, VOs e DTOs que assombram ate mesmo os menores projetos do mundo....

Tente simplificar sua arquitetura, itnerfacei os objetos, ai quando voce precisar voce vai ter a flexibilidade necessaria, sem ter de criar algo gigante desde o inicio.

Vou tentar simplicar o maximo mesmo, retornando os arquivos mapeados do JPA pra camada de apresentacao mesmo e utilizar Lazy Loading (na arquitetura anterior iria usar os inicialize para carregar os atributos marcados como Lazy)
Creio que algo como JSF -> Managed Bean -> Facade -> Service (acessando os pojos de persistencia) seria o suficiente mesmo nao acha?

Vlw pela ajuda

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

ffranceschi wrote:
Vou tentar simplicar o maximo mesmo, retornando os arquivos mapeados do JPA pra camada de apresentacao mesmo e utilizar Lazy Loading (na arquitetura anterior iria usar os inicialize para carregar os atributos marcados como Lazy)
Creio que algo como JSF -> Managed Bean -> Facade -> Service (acessando os pojos de persistencia) seria o suficiente mesmo nao acha?

Vlw pela ajuda

Oi, ffranceschi

Sei q já tem o maior TEMPÃO o post levantado! Porem, agora estou fazendo 1 pesquisa s/ DomainModel, DDD, DSL, etc. e achei esta mini-discussão muito interessante!

Gostaria de saber seus insights q teve na prática enquanto desenvolvia o seu Sistema e qual Arquitetura (camadas, tier) q efetivamente usou no Sistema.

Saberia dizer a vantagens e desvantagen, as dificuldades e se tivesse q fazer (Dnovo) algo de outra forma, se vc usaria alguma ferramenta p/ ajudar/automatizar o processo?!!

Desde já grato p/ informações e impressões,

Derlon

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

derlon wrote:

ffranceschi wrote:
Vou tentar simplicar o maximo mesmo, retornando os arquivos mapeados do JPA pra camada de apresentacao mesmo e utilizar Lazy Loading (na arquitetura anterior iria usar os inicialize para carregar os atributos marcados como Lazy)
Creio que algo como JSF -> Managed Bean -> Facade -> Service (acessando os pojos de persistencia) seria o suficiente mesmo nao acha?

Vlw pela ajuda

Oi, ffranceschi

Sei q já tem o maior TEMPÃO o post levantado! Porem, agora estou fazendo 1 pesquisa s/ DomainModel, DDD, DSL, etc. e achei esta mini-discussão muito interessante!

Gostaria de saber seus insights q teve na prática enquanto desenvolvia o seu Sistema e qual Arquitetura (camadas, tier) q efetivamente usou no Sistema.

Saberia dizer a vantagens e desvantagen, as dificuldades e se tivesse q fazer (Dnovo) algo de outra forma, se vc usaria alguma ferramenta p/ ajudar/automatizar o processo?!!

Desde já grato p/ informações e impressões,

Derlon

A pergunta foi pro ffranceschi, mas vou dar meu pitaco...

Se vc quer integrar JSF com Hibernate (JPA) a melhor ferramenta q vc tem hoje é o Seam.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

andre_salvati wrote:

A pergunta foi pro ffranceschi, mas vou dar meu pitaco...

Se vc quer integrar JSF com Hibernate (JPA) a melhor ferramenta q vc tem hoje é o Seam.

Oi Salvati, blz?!!

Ah, claro! (U're quite sure) Vc tem razão totalmente. Para o cenário mencionado não há toolware + simples, prático e eficaz. (não obstante alguns EQUIVOCADAMENTE dizer q ele te deixa preso ao JBoss. Inclusive, quero gerar 1 Projeto em Seam rondando no Glassfish e no TomCat (q como sabem NÃO é container EJB) para provar o contrário

, porém infelizmente isto vai ficar p/ 1 segundo momento.

)

Então, vou refazer minha pergunta (apesar de 1 pouco OffTopic).

Na verdade, tb estou afim de trocar o JSF p/ 1 framework + CoC(ConventionOverConfiguration) como o vRaptor (2 ou 3), sacou?!!

Com o Seam nós usamos o Hibernate em modo StateFull (da forma correta COMO DEVE SER USADO, de acordo c/ Galvin King). Então minha maior (concern) preocupação é como devo gerenciar a Session e as Transações, com trio JPA(Hibernate)/Spring/vRaptor. Em qual camada devo gerenciar isto?!!

Grato pelas opniões e dicas,

(c/ futura adição de AJAX: dica e truks são muito bem vindos)

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

derlon wrote:

Então minha maior (concern) preocupação é como devo gerenciar a Session e as Transações, com trio JPA(Hibernate)/Spring/vRaptor. Em qual camada devo gerenciar isto?!!

Não uso o Seam com vRaptor, portanto não sei como ficaria. Pq vc precisa do Spring? Não há um equivalente para o que vc procura no Spring no Seam?

Sugiro que vc use o Seam com JSF mesmo, caso contrário seu projeto virará um frankstein de frameworks...

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

Bom, Frankstein por Frankstein, o JSF ja o é por si só, por mais que o Seam se esforce pra simplifica-lo.

Falando serio agora, eu tbm estou fazendo alguns testes com o VRaptor na esperanca de me livrar do JSF, o framework é simples, intuitivo e produtivo, a unica coisa da qual estou apanhando um pouco é a mudanca de conceito. Eu tbm sempre usei meus objetos armazenando sempre o estado na sessao, (ou no keep alive no caso do richfaces).

No vraptor isso é um pouco mais complicado (ou eu nao achei uma forma simples ainda), tenho uma fachada que mantenho no escopo da sessao guardando o estado do objeto, injeto ela no controller e pronto, tenho um objeto stateful. O problema é no caso de edicao (por exemplo), o bean que ele passa no metodo é sempre uma nova instancia, entao eu tenho que remontar algumas dependencias a cada requisicao.

Nao sei se é uma mudanca de conceito, ao qual nao estou adaptado, ou falha minha na interpretacao do framework, mas essa tem sido minha unica dificuldade, embora facilmente contornavel.

Quanto as sessions do hibernate e afins, continua exatamente da mesma forma como era antes com JSF, na ha mudanca alguma, o Spring cria a sessionFactory, injeta uma session nos repositorios e eu os acesso atraves daquele facade que me referi antes.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

Em 1° lugar, desculpe p/ demora no reply do post (estava fazendo 1 profunda pesquisa s/ DSLs internas (fluent interfaces) e Language Workbench).
YvGa, muito obrigado p/ reply (de extrema valia p/ mim)!!

YvGa wrote:Bom, Frankstein por Frankstein, o JSF ja o é por si só, por mais que o Seam se esforce pra simplifica-lo.

Sempre acreditei na Inciativa da Sun, o JSF, para Componentização na CAMADA DE VISÃO (VIEW). Entretanto, quanto + eu tenho contato c/ JSF, + eu o detesto.

Realmente, chamá-lo de Frankstein é 1 elogio, principalmente no que se refere à parte de WebFrontController: isto mesmo, os famigerados ManagedBeans -> karamba, bixu, toda JSP(c/ JSF) tem q ter o seu "Code-Behind"; até no dinossauro Struts1, vc pode associar várias páginas à 1 só Action. O JSF como WebFrontController é macaio D+ mesmo!

YvGa wrote:
.
.
.

Quanto as sessions do hibernate e afins, continua exatamente da mesma forma como era antes com JSF, na ha mudanca alguma, o Spring cria a sessionFactory, injeta uma session nos repositorios e eu os acesso atraves daquele facade que me referi antes.

Ah, gostaria de saber qual é a versão do SpringFramework q vc está utilizando?! Tô afim de fazer +/- o q vc está fazendo, só q Injetar as Dependencias (ou Recusos) via Annotations => Spring 3. Mas, como estou querendo implementar seguindo a especificação JPA(2), em vez da Session(Facade) do Hibernate, usamos o EntityManager (Factory). Então, preciso pesquisar 1 pouquinho + s/ isto. Sobre o vRaptor, após pegar alguma prática (e eventualmente compará-lo com o Seam Framework), espero retornar aki p/ trocarmos algumas ideias.
Novamente, grato

Derlon

Notícias, artigos e o maior fórum brasileiro sobre Java