Pojos do Hibernate devem ser Objetos de Dominio?

Pessoal, tenho lido em alguns posts sobre não utilizar modelos anemicos e tudo o mais. Minhas dúvida é que em alguns casos eu não consiguo transformar os POJOS do Hibernate em um modelo OO conforme deveria ser. Então geralmente os POJOS do hibernate devem sempre ser minhas classes de domínio, onde eu vou ter regras de negocio e tudo o mais, ou eu devo criar dois pacotes, um para POJOS do Hibernate e outro para Objetos de Dominio? E ai na minha camada de Services por exemplo eu traduziria os Objetos de Dominio para os Pojos do Hibernate e vice-versa?

1 curtida

Cara,

Acho bastante interessante tb estes conceitos de não utilizar modelos anemicos e etc, porém na minha opinião, isto não pode causar duplicidade, como vc descreveu, entre a camada de dominios e o hibernate anemico…

O negócio é ser simples… duplicações são sempre custosas de manter…

[]'s

Como nosso colega fpavao falou, evite duplicidade. Simplesmente anote suas classes de domínio com as tags do Hibernate. Se não quiser sujar as classes com anotações do Hibernate, use mapeamento XML.

Poruqe não?

Colega, não existem POJOs do Hibernate.

[quote=spranta]Então geralmente os POJOS do hibernate devem sempre ser minhas classes de domínio, onde eu vou ter regras de negocio e tudo o mais, ou eu devo criar dois pacotes, um para POJOS do Hibernate e outro para Objetos de Dominio?
E ai na minha camada de Services por exemplo eu traduziria os Objetos de Dominio para os Pojos do Hibernate e vice-versa?[/quote]
Primeiro pense no seu domínio, após mapeie ele para que seus objetos sejam persistentes. Não faz sentido ter 2 classes, volta-se ao mesmo problema dos VOs/BOs.

O problema aqui é o direcionamento de seu raciocínio.

Você não deve modelar seu sistema em função do banco de dados e sim o contrário.

Crie seu objetos, defina como colaboram entre sí.

Depois disso sim, faça a persistência deles.

Tabelas de relacionamento por exemplo não fazem muito sentido como objeto na minha opinião.
Um exemplo, eu tenho uma tabela de Atividade, e outra de Serviço, o relacionamento delas é de N-N, só que o relacionamento dela tem campos extras como aliquota da associação, e outros que como userCriação e dataCriação que não considero muito relativos ao objeto de dominio mas somente a auditoria do banco de dados, mas que na persistencia teem de ser considerados e portanto devem conter no pojo. Por estes fatos, percebo que eu teria de criar uma classe relativa a esta tabela de relacionamento, mas que no meu modo de ver OO não é uma classe de dominio, posso estar enganado mas é meio anti-OO ter uma classe de dominio denominada Servico_Atividade ou Aliquota_Aplicada

É uma questão de entendimento.

Até mesmo usuarioCriação ou dataCriação é parte do domínio.

Não há restrição alguma de um objeto querer saber que usuario fez sua criação ou sua data de criação.

A questão é, se isso não faz parte do domínio por que existiria dentro do banco de dados ?

OBS: Para relacionamentos e coisa e tals o hibernate tem resoluções até bem legais para isso.

[quote=nbluis]O problema aqui é o direcionamento de seu raciocínio.

Você não deve modelar seu sistema em função do banco de dados e sim o contrário.

Crie seu objetos, defina como colaboram entre sí.

Depois disso sim, faça a persistência deles.[/quote]

As vezes isso se torna complicado, o banco já existe, na minha opinião o banco que hoje é composto por umas 50 tabelas não passaria de 15 classe de dominio na minha aplicação, só que eu acho que dificilmente eu conseguiria agrupar estas 50 tabelas em tais 15 classes, ficaria muito confuso uma classe referenciando N tabelas.

Além disso, veja só, eu terei de ter CRUD’s de Tipo de Documento, Tipo de Pagamento, Tipo de Serviço e vários destes outros TIPOS, tabelas estas que devem ter um gerenciamento mas que na minha opinião não são, “Entidades de Domínio”, não tem uma identidade de objeto do mundo real, são tipos, não vão ter funcionalidade, são somente dados de apoio para distinguir (categorizar) outros dados, com se fossem flags. Enfim, eu acho que não merecem ser tratados como “Entidade de Domínio”, afinal se não tivesse no banco de dados uma tabela dela eu não criaria esta classe, seria somente um atributo de quem o usa, mas como eu tenho tal tabela e tenho de fazer seu CRUD, eu tenho de considerá-la como uma Classe separada. Estão entendendo? Com essas coisas eu acabo tendo um modelo de domínio mais relacioanal do que OO como eu gostaria, pelo fato de ter de utilizar as mesmas classes para modelo de dominio e para mapeamento objeto-relacional do hibernate.
Acho que deveriam ser somente uma classe representando ambos, como voces sugeriram, mas considero quase improvável eu conseguir manter minha modelagem OO imune as peculiaridades do modelo relacional, ou seja, sem que estas influenciem a existência de determinadas classes.

Bom.

Uma coisa imprescindível para isso funcionar é uma modelagem OO.

Se a coisa começa torta, com o sistema em função do banco de dados, logicamente o sistema terá que trilhar este caminho.

A idéia seria: “Não se modela um sistema OO a partir do banco de dados”.
Se esta premissa básica é quebrada, todo o resto pra frente pode/deve sofrer com isso.

Se “Documentos” podem ter “Tipo de Documento”, independente se “Tipo de Documento” é apenas um cadastro simples que irá se relacionar com demais objetos, ele faz parte do domínio. É bem fácil visualizar isso se começamos a trabalhar com objetos antes de pensarmos em banco de dados.

Até.

Vamos esquecer a TLA POJO por enquanto porque ela só agrega ruído na discussão. Sim, seus objetos de domínio devem ser os mesmos que são persistidos.

Se voc6e tem algo nas tabelas então quase sempre vai ter uma regra de negócio referente àquilo e por consequência vai ter objetos o modelando. Tabelas associativas geralmente persistem associações entre objetos.

Se você não consegue fazer com que seus modelo relacional legado faça sentido num modelo Orinetado a Objetos então abstraia seu modelo legado com Data Mappers ou coisa parecida.

(ps: movido para Java, isso eh Hibernate, nao arquitetura)

[quote=nbluis]É uma questão de entendimento.

Até mesmo usuarioCriação ou dataCriação é parte do domínio.

Não há restrição alguma de um objeto querer saber que usuario fez sua criação ou sua data de criação.

A questão é, se isso não faz parte do domínio por que existiria dentro do banco de dados ?
[/quote]

Controle. Se vc implementar um mecanismo de concorrência otimista vc precisa de um campo version no registro.
Esse campo não tem nada a ver com domínio. Ele pura e simplesmente usado para controlar concorrência que é um requisito não-funcional e portanto não pode ser considerado do domínio. O mesmo se pode aplicar a user e datacriação, dataalteração, chave , etc… tudo informações necessárias a requistos não-funcionais que não pertencem ao domínio.

No caso particular do Hibernate ( que é uma implementação do padrão DomainStore) a resposta é sim: os seus objetos de dominio são os objetos que vc hiberniza. Vc tem objetos de dominio (Domain) e uma forma de os preservar ( DomainStore).

No caso geral a resposta é não. Objetos de Dominio nem sempre tem que ser objetos persistiveis. Vc pode ter um sistema com objetos de dominio e um mecanismo de persistencia baseado em JDBC puro que não está nem ai para o seu dominio. No caso particular em que o banco já existe antes do sistema ( um legado ) vc adota esta posição.

Mas lembre-se , o dominio não reflete a persistencia, nem a persistencia reflete apenas o dominio.
As classes do dominio são criadas para fazer o sistema funcionar. Suas relações podem ser mais ou menos complexa que o banco. Como foi dito, nem sempre relações N-M que no banco são 3 tabelas se refletem em 3 classes. Por outro lado, a informação que está no banco não tem que ser toda traduzida para campos de classes. Algumas informações podem ser incluidas pelo proprio mecanismo de persistencia, por exemplo.

É por isso que sempre se fala em mapeamento, mas o mapeamento não é 1:1 para tabelas-classes nem para campos-attributos.

Colega, não existem POJOs do Hibernate.
[/quote]

:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:

Ahm?

[quote=sergiotaborda][quote=spranta]
o mapeamento não é 1:1 para tabelas-classes nem para campos-attributos.
[/quote]

Concordo, principalmente quando se fala tabelas-classes. Mas em relação a campos-attributos eu não vejo isso muito claro, veja só o caso do UserCriacao e dataCriacao, isso nao faz parte do meu dominio e portanto eu nao crio atributos para eles nas minhas classes, no entanto na persistencia eu preciso informá-los, então eu teria que persistir meu objeto de dominio via hibernate e depois atualizar aquele mesmo registro via jdbc nos campos referentes a userCriacao e dataCriacao?

Colega, não existem POJOs do Hibernate.
[/quote]

:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:[/quote]

Eu acredito que o colega se referia a: pojos mapeados com hibernate