Modelo Dominio com Annotations?

4 de fevereiro de 2007 9 respostas

agostinho 4 de fevereiro de 2007

Imagine um modelo de dominio qualquer, com seus respectivos códigos de negocios. Sao POJOS puros, desacoplados do banco de dados e reutilizaveis. Agora imagina que vc precisa que essa aplicacao seja distribuida, usando EJB 3. Vc precisa persistir os dados no banco, usando a recente JPA, que usa annotations.

Pergunta: dessa forma, eu nao estaria violando meu modelo de dominio, pois alem de poluir os POJOS com a annotations, tmb é possível escrever consultas usando a JPA??! Veja o trecho de codigo abaixo, retirado de um artigo da JavaMagazine 39, só pra mostrar o quanto annotations podem poluir:

....
@Entity
@NamedQueries( { @NamedQuery(name = "Reserva.listarPorPeriodo", 
		                     query = "SELECT r FROM Reserva r WHERE " +
		                     		"r.inicio >= :inicio AND r.fim <= :fim"),
		                     		
         		 @NamedQuery(name = "Reserva.ultima", 
                             query = "SELECT r FROM Reserva r WHERE r.codigo = " +
             				         "(SELECT MAX(r1.codigo) FROM Reserva r1)")                     	        	         	 		                     			
			   }
)
public class Reserva {
	@Id
	@Column(name = "CD_RESERVA")
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Integer codigo;

	@ManyToOne
	@JoinColumn(name = "CD_CLIENTE", nullable = false)
	private Cliente cliente;

	@ManyToOne
	@JoinColumn(name = "DS_PLACA", nullable = false)
	private Veiculo veiculo;

	@Column(name = "DT_INICIO", nullable = false)
	@Temporal(TemporalType.DATE)
	private Date inicio;

	@Column(name = "DT_FIM", nullable = false)
	@Temporal(TemporalType.DATE)
	private Date fim;

	// gets, sets
	// possiveis metodos de negocios...
}

Na minha opiniao, isso nao está certo. O ideal seria manter os POJOS sem esse tipo de codigo.

Isso ai de cima nem parece um POJO. O que acham ??!
Obrigado pela ajuda.

9 Respostas

WilliamSilva 4 de fev. de 2007

Olá agostinho ,

Na minha opiniao, isso nao está certo. O ideal seria manter os POJOS sem esse tipo de codigo.

Isso ai de cima nem parece um POJO. O que acham ??!
Obrigado pela ajuda.

Digamos que o código acima não ficou perfumado o suficiente, observe que a intenção dos autores “André Dantas e Sérgio Oliveira” foi mostrar a Persistencia no Java EE5 ou melhor a “JPA” (suporta POJOs e annotations) usando Toplink Essentials em nenhum momento foi discutido “Modelo de Dominio” que é um conceito muito interessante ou Injeção de Dependência (ID) , e sim como os próprios autores escreveram no escopo do artigo.:
" Na JPA os objetos persistentes são denominados entidades(entities).Uma entidade é um objeto simples(POJO), que representa um conjunto de dados persistido no banco."
Para uma discussão mais “crítica” seria interessante vc. primeiro efetuar uma leitura da revista Mundo Java nums.:

14 ==> “A evolução da arquitetura Enterprise JavaBeans” - de: Givanildo Santana.
-15 ==> “Arquitetura de Camadas em Java EE” - de:
Phillip Calçado.
-17 ==> " Desenvolvendo Sistemas OO com Padrões de Negócios" de:
Phillip Calçado.
20 ==> " Enterprise Java Beans 3.0" de:
Nico Steppat e Paulo Silveira.

E é até interessante notar na edição num 17 a seguinte observação do Phillip.:
" POJO… não é uma definição rígida, mas indica classes que não implementam interfaces, ou extendem classes de um framework especifico…" .

Alguns exemplos interessantes.:
http://cwiki.apache.org/S2WIKI/struts-2-spring-jpa-ajax.html

Exemplo JPA - Java Persistence API
http://www.furutani.eti.br/

sds
William Silva.

agostinho 4 de fev. de 2007

Oi William,

Eu li todos os artigos citados da Mundo Java. E nao to querendo criticar o artigo da java magazine, eu sei que era um exemplo simples apenas para demonstrar o uso da JPA, sem se preocupar com mais nada.

Mas com essa onda de annotations em tudo quanto é lugar, fica complicado deixar os POJOS puros.

Imagina vc ter uma complexa regra de negocios e ainda por cima mapear a camada de persistencia junto, misturando…nao gosto muito dessa ideia,

eu acho que devia existir uma separacao, mas tmb alguém pode dizer que fazendo com annotations, o codigo de mapeamento se torna mais “transparente”…

valeu.

chun 4 de fev. de 2007

agostinho:
Oi William,

Eu li todos os artigos citados da Mundo Java. E nao to querendo criticar o artigo da java magazine, eu sei que era um exemplo simples apenas para demonstrar o uso da JPA, sem se preocupar com mais nada.

Mas com essa onda de annotations em tudo quanto é lugar, fica complicado deixar os POJOS puros.

Imagina vc ter uma complexa regra de negocios e ainda por cima mapear a camada de persistencia junto, misturando…nao gosto muito dessa ideia,

eu acho que devia existir uma separacao, mas tmb alguém pode dizer que fazendo com annotations, o codigo de mapeamento se torna mais “transparente”…

valeu.

Eu acho que voce esta procurando pêlo em ovo… anntations sao apenas comentarios em uma classe… se voce se encomoda tanto utilize um descritor XML separado ( que sinceramente eu acho que eh retroceder no tempo… ) EJB3 suporta XML no estilo antigo.

WilliamSilva 4 de fev. de 2007

Agostinho,

Eu vejo as regras de negócios  dentro de um "Modelo de Dominio" e a camada de persistência nem irá saber que tal modelo existe para isso tenho liberdade de usar JPA,Hibernate etc.
   Sou meio redundante quando cito os artigos do PCalçado e alguns outros  desenvolvedores que tomo como exemplo porquê o conceito correto está ali, não que seja uma verdade absoluta e eles sabem disso, mais o modelo é  colocado para discussão e análise em exemplos reais sem fantasias.

agostinho 4 de fev. de 2007

Oi William,

Tmb tenho o “Shoes” como referencia. Os artigos deles sao muito bons.

Em relacao a usar annotations, eu estou encarando como se fosse uma maneira transparente de mapeamento para a camada de persistencia.

E pelo que andei lendo, o proximo padrao vai ser JPA, ne?! Entao…vamos la… :-o

pcalcado 4 de fev. de 2007

Anotações não são comentários, são meta-dados e como tal devem ser tratados com a mesma seriedade que código.

Existe uma séria divergncia entre utilizar meta-dados em classes de domínio ou não. Na minha opinião meta-dados não são problema ser você os utiliza para descrever associações entre objetos, até mesmo IoC. O problema é quando você começa a colocar configuração e outros dados que dizem respeito apenas ao ambiente de execução ou framework e devem estar ocultos e encapsulados, não expostos aos objetos de negócio que só se preocupam com as tais regras de negócio.

J2Alex 5 de fev. de 2007

A grande questão que acho em relação a isso é que enchemos o pojo com semânticas de um framework específico… isso acho ruim.

Se temos somente o pojo, sem anotações, poderemos utilizá-los em outro framework de persistência, sem problemas. Com anotações também poderemos, mas os pojos ficam poluídos.

Cria-se, assim, um certo nível de dependência que não acho muito interessante… estamos amarrando, até certo ponto, o pojo a um framework específico.

carneiro 5 de fev. de 2007

Bem, tudo com moderação fica legal. Não acho que as anotações do JPA poluam o código.

Mas, declarar NamedQuerys em pojos é horrível, eu jamais usaria isso. Prefiro deixar no código de cada método do meu DAO mesmo, a ter 50 linhas de anotações para as consultas.

okara 6 de fev. de 2007

Na minha humilde opinião, o problema não é usar meta-dados no código, se este é relativo a regra de negócios.
Agora se vc olhar por uma visão “puritana”, colocar nomes de tabelas, campos e selects no meu das annotations é que fica estranho.
Mas como disseum de nossos colegas, quem se encomoda com isso use o XML, (eu ainda prefiro).

Criado 4 de fevereiro de 2007

Ultima resposta 6 de fev. de 2007

Respostas 9

Participantes 7

9 Respostas

Topicos relacionados