[quote=AvilaCS]Pessoal, não consigo ver o porque de não utilizar anotação JPA em minhas entidades!!
Alguém poderia passar alguns motivos?[/quote]
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.
[quote=pcalcado]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.[/quote]
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?
[quote=rodrigoy]Que risco você enxerga nas anotações da JPA e EJB3, Phillip?
[/quote]
Imagine um exemplo simples:
@Entity
@Table(name="tbl_sky")
public class Sky implements Serializable {...}
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 
[quote=pcalcado]
O grande problema eh que nao temos muita escolha. Se nao tem remedio remediado esta. Por enquanto ;)[/quote]
Concordo!
Não temos muita escolha mesmo, já que a meneira como Java trata metadados é pura gambs.
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:
- 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)
[code]package se.citerus.dddsample.domain.model.cargo;
import java.util.List;
public interface CargoRepository {
/**
- Finds a cargo using given id.
-
-
@param trackingId Id
-
@return Cargo if found, else {@code null}
*/
Cargo find(TrackingId trackingId);
/**
- Finds all cargo.
-
-
@return All cargo.
*/
List<Cargo> findAll();
/**
- Saves given cargo.
-
-
@param cargo cargo to save
*/
void store(Cargo cargo);
/**
-
@return A unique, generated tracking Id.
*/
TrackingId nextTrackingId();
}[/code]
OBS: Esse CargoRepository está sendo implementado na camada de infraestrutura.
-
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?
-
Vou postar meu diagrama de projeto de classes aqui logo mais, e a estrutura das minhas classes como está ficando.
att
fidencio.
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.
[quote=PedroTOliveira]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.
[/quote]
Posso concluir que JPA/Hibernate é um mapeador de objetos para modelo relacional e vice-versa? ou um DataMapper ?
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.
