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.
[quote]
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.[/quote]
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…" .
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”…
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.
[/quote]
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.
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.
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.
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.
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.
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).