Padrão e Anti-Padrão em Hibernate/TopLink

Programação Arquitetura
#1

Seguinte…

Parece que o pessoal está comprando a idéia de mapeamento OO mas que o pessoal arruma… lastimável.

Anti-Padrão:
Objetos-Tabelas
Forma-Geral:
Objetos que são persistidos num banco de dados, são o mapeamento direto entre classes e tabelas (e entre campos e atributos).
Contexto:
Primeiro, toma-se um legado com uma estrutura de banco de dados, um tanto quanto discutível: uma tabela que inicialmente servia para atender um sistema passa a atender várias outros. Além disso os sistemas evoluem mas tabela mas sofre modificação. A tabela estão já não carrega o valor semântico esperado.
Então, resolve-se que o sistema precisa ser convertido para OO. Para isso, utiliza-se um serviço de persistência objeto/relacional, mas mapeamento é mera conversão entre tabelas e classes. Desse modo, as classes tem ainda menos significado que as tabelas.

Conseqüência:
Performance sofrível da aplicação. Um monte de queries igualmente sofríveis em alguma variante de sql. Multiplicação de objetos com a criação de objetos de negócio + objetos-tabelas + conversores.

Solução refatorada:
Fazer um mapeamento entre objetos de negócios e tabelas de banco de dados, eliminando o objeto intermediário.

O problema é. Eu não consigo fazer o pessoal acreditar nisso. Então eu gostaria de pedir um favor para quem já tenha feito um mapeamento redondo entre objetos de negócio e tabelas de banco de dados. Post um exemplo aqui de uma classe de negócio que não tem nada a ver com a representação dele no banco de dados e como foi feito o mapeamento.

Desesperadamente,

#2

Hibernate pode ser usado para criar o equivalente a views materializadas dos RDBMS modernos. Eu uso, por exemplo, para objetos que são sumários de uma penca de linhas do banco.

#3

Louds,

Legal! Poderia me mostrar algum exemplo real.

Vou citar alguns exemplos teóricos (Vou tentar enriquecer o tópico):

Seja uma tabela com um campo blob.
Muitas vezes queremos listar os registros dessa tabela mas sem o conteúdo do blob.
Outras vezemos queremos o conteúdo dos registros com o blob.
Solução: utilizar duas classes (de preferência com herança) e dois mapeamentos para uma mesma tabela. Numa das classes teremos um mapeamento parcial (sem o blob) e na outra, total.

Seja uma tabela com um relacionamento (digamos 1:N).
Muitas vezes queremos listar os registros dessa tabela mas sem o relacionamento.
Solução: Utilizar lazy-loading.

Outras vezes, como no caso de relatórios, queremos o objeto completo, carregado de uma única vez.
Solução: Utlizar lazy=“false”

Na verdade, existem várias estratégias de fetching bastante interessante, a maioria delas eu não domino. Mas é possível, por exemplo fazer carregar uma coleção com paginação (isto é, o resultado da query não vem de uma única vez, mas em várias páginas).

http://www.hibernate.org/315.html

[]´s

#4