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.

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)

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

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

derlon:

ffranceschi:

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.

andre_salvati:

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 :evil: , porém infelizmente isto vai ficar p/ 1 segundo momento. )

Então, vou refazer minha pergunta (apesar de 1 pouco OffTopic). :oops: Na verdade, tb estou afim de trocar o JSF p/ 1 framework + CoC(ConventionOverConfiguration) como o vRaptor (2 ou 3), sacou?!! 8) 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?!! :shock:
Grato pelas opniões e dicas, (c/ futura adição de AJAX: dica e truks são muito bem vindos)

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…

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.

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:

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. :x 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! :shock:

YvGa:

.
.
.

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