DDD e JPA - Onde vão as annotations?

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

emerleite wrote:

Lezinho wrote:Anotações são apenas informações jogadas ao vento, não são códigos.
No caso do JPA, sua classe continua sendo POJO se apenas for anotada, mas deixa de ser se você utilizar EntityManager dentro dela (por isso use a abstração oferecida por um Repository).

O que tem a ver ter um atributo de instância com ser um POJO ?

O termo quando foi cunhado por Fowler, tinha como objetivo dar um nome para classes Java simples, aquelas que não tinham necessidade de estender nem implementar nada de frameworks em específico que lhe rotulassem algo . Porém o termo é apenas uma referência, não é uma regra... mas isso é gosto particular. Tem gente que chama POJO de Bean e esta super bem com isso, outras pessoas acham que JavaBeans é apenas a definição de componentes para GUIs & RADs, etc.

Eu *particularmente* não chamo classes que dependem da infraestrutura de frameworks que lhe ditam como deve ser seu comportamento, de POJO.

This message was edited 2 times. Last update was at 26/11/2007 14:05:21

Lezinho wrote:Tem gente que chama POJO de Bean e esta super bem com isso, outras pessoas acham que JavaBeans é apenas a definição de componentes para GUIs & RADs, etc.

Pois é, você tem razão quanto a isso mas esse problema é que agente mesmo critica pois tinha gente aqui que chamava Repositório de DAO em diversas discussões do GUJ dizendo que eram a mesma coisa e que se sentiam bem chamando assim.

Eu concordo com você que o termo é só uma referência e eu já havia lido o texto do Fowler, porém o mais aceito na nossa comunidade para POJO e as principais referências tem mais a ver com a não necessidade da classe em obedecer contratos de fameworks do que o conteúdo interno da mesma.

Em fim, eu queria só saber por que você tinha dito isso.

Eu uso Annotations. Eu sou muito mais feliz depois do Java 1.5 com suas Annotations.

Quem me conhece sabe que detesto xml para configurar e introduzir comportamentos no código. As Annotatins acabaram com isso, um bom exemplo de bom uso delas é o Hibernate e o JPA.

Então eu anoto diretamente minhas Entitys com as Annotations JPA ou Hibernate.

Pessoal, não consigo ver o porque de não utilizar anotação JPA em minhas entidades!!
Alguém poderia passar alguns motivos?

Java Ninja Membro desde: 31/01/2003 10:21:32 Mensagens: 260 Offline

Gostei do camaradinha ai que disse pra ter BOM SENSO!

Tudo vai do projeto que você está trabalhando...

1- Qual a finalidade?
2- Sua entidades serão usadas somente neste projeto?
3- Haverá mesmo a necessidade de outras aplicações usarem estas entidades?
4- Tem certeza que vão usa-las mesmo?
5- Certeza absoluta?
6- Essas aplicações não vão usar JPA?
7- Certeza que não vão?

Então, cara, depende do projeto que você está trabalhando, do ambiente de desenvolvimento e execução das aplicações. É bom senso!

Haverá casos que usar anotações JPA serão tiro no pé. Outros que serão a salvação! Porque, meu chapa, configurar arquivos XML é um saco! E a possibilidade de erro aumenta de verdade...

Não dá pra ser xiita em desenvolvimento de software. O lance é: Resolva o problema do seu cliente da melhor forma!

E outra coisa: Faça o mais fácil; não se preoculpe com 100% dos problemas que podem acontecer num futuro distante, da ordem de 1%. Pense no agora e no daqui a pouquinho, não no daqui a 2 anos. Muita coisa muda!

Se o que alguém definiu como técnica XPTO serve pra você, ótimo! Se não serve 100%, tente adaptar para a sua necessidade. Não se a adaptação não for viável, mude para a técnica OTPX.

O lance é: Não é o seu a necessidade de software do seu cliente que tem que se adequar à técnica XPTO, mas sem a técnica XPTO te ajudar a atender 100% das expectativas do seu cliente.

Agrade o cliente com resultados 100% positivos, não às técnicas que deixam o seu cliente apenas 80% feliz.

Entregue o software que o seu cliente quer. Com as funcionalidades que ele quer.

Software funcionando e de qualidade total, este é o lema!

É o que eu penso...

Abraço!

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

AvilaCS wrote:Pessoal, não consigo ver o porque de não utilizar anotação JPA em minhas entidades!!
Alguém poderia passar alguns motivos?

Pense no problema de extender um classe específica de um framework como no caso do Struts 1. Qual é o problema de extender?

O problema é que seu sistema fica atrelado ao framework struts. Aí rebuscaram o POJO nos frameworks mais novos, só que surgiu o problema dos metadados. Aí vieram com as annotations. Pensamos, com annotations minha classe é POJO, pois não extende nenhuma classe. Ótimo.

Mas o problema maior agora é a linha: import javax.persistence.Entity; por exemplo. Essa linha faz com que sua classe não compile sem o jar do JPA por exemplo. Ou seja, o acoplamento com alguns frameworks ainda existe. E foi o que gerou essa discussão.

Como o Philip falou, evitar ao máximo o uso de annotations no Domain. Obviamente as pessoas tem dificuldade de ver problema nisso, pois a maioria dos projetos não reusa o Domain para outros ambientes.

Imagine que seu Domain deva ser usado para ambiente Web e ambiente Mobile. Com anotações JPA na sua classe de Domain, terá que arrastar o jar do JPA para o ambiente Mobile (Nem precisa dizer que 2MB para o JPA funfar não é bom pra mobile né?).

Mas a parte do bom senso matou a pau, pois se você tem certeza de que sua aplicação não vai pra outro ambiente, esqueça essa discussão.
Se você for purista e gostar muito de best pratices, procure uma solução adequada a seu caso.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

pcalcado wrote:O problema eh que metadados (annotations) acabam por criar uma outra 'dimensao' nos seus objetos. Minha dica eh:

- use o que for mais simples
- nao perca muito tempo viajando sobre annotations ao inves de fazer seu trabalho, eh confuso mesmo
- nao espalhe as anotacoes de infra pelas classes o quanto puder mas sem radicalismos

A forma com que os metadados sao usados em Java eh pessima. Metadados deviam fazer tagging apenas.

Concordo contigo. Acho que as annotations seriam muito melhores se não fosse necessário importar dentro da Tag, pois aí seriam simplesmente ignoradas na falta do Jar e funcionariam em qualquer ambiente.

Só por curiosidade, você vê alguma situação onde escrever duas classes com os mesmo atributos seja interessante? Uma classe para a persistência e outra para o Domain?

rodrigoy wrote:Que risco você enxerga nas anotações da JPA e EJB3, Phillip?

Imagine um exemplo simples:

Temos nestas linhas informacao que nao pertence ao dominio mas esta definida dentro da classe de dominio Isso eh ruim do ponto de vista da modelagem de negocios mas eu ainda tenho duvidas obre o real impacto em modelagem.

O grande problema eh que nao temos muita escolha. Se nao tem remedio remediado esta. Por enquanto

Java Ninja Membro desde: 31/01/2003 10:21:32 Mensagens: 260 Offline

pcalcado wrote:
O grande problema eh que nao temos muita escolha. Se nao tem remedio remediado esta. Por enquanto

Concordo!

Não temos muita escolha mesmo, já que a meneira como Java trata metadados é pura gambs.

rodrigoy wrote:Bom senso... bom senso... bom senso... desenvolvimento de software se resume a bom senso!

Rodrigo, sei que o post já é meio antigo, porém toda discussão que gera idéias magnificas como este, considero-o de suma importância dentro do contexto. Portanto, segue alguns questionamentos e dúvidas de minha parte:

1. Eu sempre fui adepto a desenvolver software usando padrões arquiteturais do GoF(Strategy, Facade, Singleton, Composite) e os Patters da SUN para especificação J2EE(Não estou dizendo que no DDD não usamos esses patterns), detalhe isso quando precisei de usar os tais (Não usei só prá dizer que usei padrão XY e Z) e outra o que estou me referindo e da arquiteturra BOLOVO (BusinessLayer, LayerObject, ValueObject)..usando e abusando de Transaction Scripts(Como você citou no teu blog) gerando um forte acoplamento entre as classes e quebrando e diminuindo a coesão (SRP - Principio da Responsabilidade Unica).
Porém agora estou desenvolvendo meu projeto (ERP segmentado para o ramo varejista) dirigido ao Dominio (DDD). Já andei lendo o livro do Evans, os Posts do Fowler, Adam Bien, GUJ..efim, revirei tudo antes de iniciar um projeto com DDD. Percebi que no DDD existem os Patterns que o acompanham e os anti-patterns, que porcerto contrariam os principios. vi aqui: http://www.infoq.com/articles/ddd-in-practice. Observei também que deve ser usar uma linguajar de negocio na manipulação dos artefatos, visto que todos envolvidos, Team, StakeHoldes, ScrumMaster, ProductOwner falam a mesma lingua(linguagem do dominio). Uma coisa que achei interessante no teu http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/, você comentou também acerca de nomeclaturas, ou seja, eu tenho um repositorio de Pedidos, então não
sou obrigado a chama-lo de PedidoRepository, ou melhor, nem vejo isso como obrigação ou posso até está sendo tolo em ser influênciado a fazer isso, porquanto trata-se de convenção, afim de faclitar a idenficação, No Entanto eu concordo contigo, imagina o cliente ver esse diagrama de classes , será que ele vai saber o que significa esse tal de PedidoRepository? Pergunto isso porque muitos estão se levando a fazer isso, ou seja, colocar como sufixo da classe o nome do Pattern e eu estava pensando em fazer isso, porém nos Exemplos que achei pela net inclusive o proprio exemplo usando pelo Evans do Sistema de Transporte de Carga a interface se chama CargoRepository. É obvio que cada caso é um caso, e como você disse temos que ter Bom senso, e nesse caso eu acho que você usou o bom senso, porquanto eu achei extremamente lógico a tua colocação, eu achei mais limpo e mais claro na visão de Business Expert.
(Lembrando que to fazendo papel de Domain Expert tambem, porquanto conheço o ramo de negocio por 7 anos)

OBS: Esse CargoRepository está sendo implementado na camada de infraestrutura.

2. Outra coisa que eu queria te perguntar. Vocês estão falando acerca de Annotations, se usa-la dentro do Dominio estaremos poluindo nossas classes de dominio. Eu particulamente acho isso horrivel, se pudesse usar JPA sem annotations, se alguem conheçe me avisa, so não uso hibernate puro porque quero me beneficiar da JPA2. O que você acha disso? Uso Hibernate como implementação, sem anotação e sem chance de abstração ou JPA com anotação com N implementação e com chance de abstração do provider ORM?

3. Vou postar meu diagrama de projeto de classes aqui logo mais, e a estrutura das minhas classes como está ficando.

att
fidencio.

JavaChild Membro desde: 03/09/2010 10:44:54 Mensagens: 111 Offline

Olá amigos eu tive essa mesma dúvida (E ainda me questiono bastante a respeito).

No meu caso o problema não estava somente relacionada a questão de colocar anotações na minhas Domain Classes mas também com o fato de que as minha entidades de domínio tinham um modelo diferente das minhas tabelas no banco de dados e em determinados casos eu poderia acessar outros Datasources que não eram tabelas em um banco relacional.

Nesse caso eu criei uma outra camada e separei com interfaces que chamei de Repository e neles eu injeto DataMappers fazendo sempre o mapeamento do Domínio para a Camada de Integração.

O padrão relacionado que encontrei é o http://martinfowler.com/eaaCatalog/dataMapper.html

Nesse caso eu ganhei porquê tornei meu domínio totalmente independente do framework de persistência, porém perdi aumentando a complexidade do mapeamento dos dados para o modelo de persistência.

PedroTOliveira wrote:Olá amigos eu tive essa mesma dúvida (E ainda me questiono bastante a respeito).

No meu caso o problema não estava somente relacionada a questão de colocar anotações na minhas Domain Classes mas também com o fato de que as minha entidades de domínio tinham um modelo diferente das minhas tabelas no banco de dados e em determinados casos eu poderia acessar outros Datasources que não eram tabelas em um banco relacional.

Nesse caso eu criei uma outra camada e separei com interfaces que chamei de Repository e neles eu injeto DataMappers fazendo sempre o mapeamento do Domínio para a Camada de Integração.

O padrão relacionado que encontrei é o http://martinfowler.com/eaaCatalog/dataMapper.html

Nesse caso eu ganhei porquê tornei meu domínio totalmente independente do framework de persistência, porém perdi aumentando a complexidade do mapeamento dos dados para o modelo de persistência.

Posso concluir que JPA/Hibernate é um mapeador de objetos para modelo relacional e vice-versa? ou um DataMapper ?

JavaChild Membro desde: 03/09/2010 10:44:54 Mensagens: 111 Offline

No meu caso o DataMapper virou o mapeador das minha classes de Dominio para as Entities do JPA (Espelho da minha base) e vice-versa.

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