Paradigma de persistência: DAO, Data Mapper, EJB like,

Programação Arquitetura
#1

Olá,

ando olhando alguns padrões, frameworks, livros, etc…

Bem… tentando encontrar uma arquitetura interessante para a camada de negócios juntamente com a de persistência, temos algumas opções:

  • DAO
  • Data Mapper, Repository, Query Object - padrões do Fowler
  • Ou ainda uma estrutura meio “EJB like”, algo como a estrutura de business layer foundation do Broemmer.

Alguém tem opiniões/considerações sobre este assunto?

Quando há uma estrutura em camadas, digamos:
±-----------------
| Apresentação
±-----------------
| Controle
±-----------------
| Negócios
±-----------------
| Persistência
±-----------------

Teoricamente, uma camada deve falar com a camada vizinha, certo?
Na minha opinião, o DAO, faz com que tenhamos algum objeto de controle fazendo dao.insert(objeto), ou seja, faz com que ele conheça DAO que é da camada de persistência. Logo, mistura um pouco as camadas…não? Será que estou errando em algo aqui?

Se fosse algo como do Broemmer, uma interface de objeto de negócio existe, definindo que os objetos de negócio terão métodos como save(), update() e delete(). E aí sim a implementação destes métodos conhecem a lógica de inserção, etc. Ou seja, a camada de negócios fala com a de persistência. E a de controle com a de negócios. Mas isso faz com que meu objeto de negócio ( persistente ) implemente uma interface. Há mal nisso?

Eu penso em ir por um caminho como o do Broemmer, ainda aplicando alguns padrões do Fowler, como o Data Mapper, Repository, etc…

Gostaria de ouvir opiniões…

#2

Estou na mesma situação, pois estou refazendo um sistema que antes era
todo baseado em procedures, a não existia modelagem de objetos, por
exemplo um cadastro de usuario tinha como parâmetro 53 atributos. Modelei
o sistema, fiz os objetos de negócio, mas dicidiram por aki por manter a
cmada de persistência como procedure, tudo bem, mas agora pelo menos eu
tenho objetos e não parâmetros independentes…:smiley:

Estou pensando em utilizar o padrão Data Mapper, para mapear meus
objetos para as queries de banco de dados, mas eu, assim como voçê, ainda
estou fazendo umas pesquisas…pois esta solução será temporária, então
queria uma coisa realmente simples. Futuramente migraremos para o
Hibernate.

Falow…

#3

[quote=“Alexandre”]Futuramente migraremos para o
Hibernate.[/quote]

Mesmo usando um Hibernate, ou outro, a dúvida permanece. Imagine que seus chefes desejem HOJE Stored Procedures. Amanhã, Hibernate, Depois, JDO, e por aí vai.

Qual design/paradigma seria melhor para facilitar esta troca?

dao.insert(objeto)
ou
objeto.save()
???

Ambos apresentam ou podem apresentar esta flexibilidade, já que o DAO em si já padroniza isso, enquanto que o caminho objeto.save() pode ser bem arrumado para padronizar isso, possuindo um Data Mapper no seu caso, ou algum objeto que seja a implementação de uma interface de persistencia, que saberia onde e como persistir: Hibernate, JDO, Data Mapper, ou Stored Procedures.

#4