Hibernate Session, Repositórios, DAO

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Pessoal,

No meu tópico anterior, discutimos um pouco sobre quem deveria ser responsável por persistir a informação no banco. No livro do Nilsson, ele sugere algo do tipo:

ISession session = SessaoDoHibernate();
RepositorioDeClientes repositorio = new RepositorioDeClientes(session);
repositorio.adiciona(x);
reposiorio.deleta(y);
session.BeginTransaction().Commit();

A implementacao de adiciona() no caso seria
_session.Save(x);
ou
vocês repassam esse session pra um DAO e este sim executa o Save()? Pq aí eu não vejo muita vantagem em ter diversos DAOs, já que o repositorio acaba recebendo o ISession do NHibernate!

Ou vocês utilizam a estratégia do Service, igual o Sérgio explicou no post anterior?

[]'s
Mauricio

This message was edited 2 times. Last update was at 29/04/2008 01:10:56

DAO traz a abstração de em qual banco voce vai persistir, neste caso representado pela Session do hibernate (que pra ser honesto é um pouco diferente que um DAO, talvez um "DomainStore" versão "DataMapper" rs, mas admita por momento que ele seja seu DAO)... Na verdade, não é necessário "vários DAOs" (em relação a representação e não a infra), o que se precisa é de vários repositórios.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

PS: o código fica melhor com o DAO injetado (do que simplesmente uma IoC manual pelo consrtrutor), pelo menos as dependencias não ficam evidentes no domínio.

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Alessandro,

O problema é que o ISession tem que ser injetado pelo construtor mesmo, pois eu posso ter diferentes Units of Work em diferentes repositórios. A idéia é de injetar o ISession (Unit Of Work) e depois deixar o UnitOfWork persistir todos os dados.

Minha dúvida é se vocês usam o próprio ISession do HHibernate como Unit of Work, ou vocês abstraem e criam seu próprio Unit of Work e implementam um NHibernateUnitOfWork...

Ou vocês no fundo, usam outra estratégia para persistir os dados, como Services, igual o Sérgio explicou! Essa estratégia do Unit of Work me agradou bastante, o código fica bem bacana!

Consegui me explicar?

[]'s
Mauricio

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

O problema é que o ISession tem que ser injetado pelo construtor mesmo, pois eu posso ter diferentes Units of Work em diferentes repositórios. A idéia é de injetar o ISession (Unit Of Work) e depois deixar o UnitOfWork persistir todos os dados.

Mas qual é a diferença de você injetar na mão ou um framework fazer a inversão pra você?

Minha dúvida é se vocês usam o próprio ISession do HHibernate como Unit of Work, ou vocês abstraem e criam seu próprio Unit of Work e implementam um NHibernateUnitOfWork...

Eu prefiro um abstractDao do que usar diretamente a implementação do Hibernate, por exemplo. No implementar eu tenho liberdade de fugir do JPA e usar features do Hibernate ou preferir seguir a risca a especificação do JavaPersistence, essa é "uma" das vantagem de abstrair. Claro que para ter um efeito melhor, as queries tbm deveriam ser abstraídas por QueryObjects... embora de um trampo maior, suas dependencias ficam menores. Mas apenas abstrair os gerenciadores, já podem ser interessantes, olhando para o repository e não vendo nenhum EntityManager por exemplo.

OBS: Os repositórios neste modelo não seriam simples "delegadores", eles conteriam as regras para a consulta. Tbm deixo claro que essa é UMA possível implementação, para cada caso pode ocorrer uma engenharia diferente para a resolução do problema motivado pelo padrão.

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Alessandro,

Nunca implementei realmente um framework de IoC, então me corrija se eu estiver errado: Com a injeção sendo feita de forma automática, eu não tenho a instância do objeto que foi injetado, a não ser que eu pegue através de um getUnitOfWork() ou algo assim, correto? E caso eu queira a mesma instância em 2 repositórios diferentes, como eu faria?

E como esse UnitOfWork é responsável pela minha persistência, como eu o chamaria? Através de um get() no repositório?

Como você resolve isso?

[]'s
Mauricio

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

MauricioAniche wrote:
ISession session = SessaoDoHibernate();
RepositorioDeClientes repositorio = new RepositorioDeClientes(session);
repositorio.adiciona(x);
reposiorio.deleta(y);
session.BeginTransaction().Commit();

Isto é tipicamente o codigo dentro de um UnitOfWork.
O Session não é um UnitOfWork é um DAO. ( Na realiaade é uma parte do DomainStore que é o Hibernate... mas ok)

A tecnologia de persistencia ( aka a API de persistencia) tem que ser chamada do DAO. Caso contrário vc tem um vinculo forte (acoplamento) com essa API. Esse vinculo não é necessáriamente ruim. Vc tem que escolher se quer usar a API directamente e se ferrar depois, ou usar o DAO e não se ferrar depois. Mas se o sistema so for funcionar por 1 mes tlv esse "depois" nunca chegue e portanto a escolha é menos relevante.
A ideia é: lei de murphy : vc vai se ferrar de qualquer jeito: use DAO.

Faça UnitOfWork ser um objeto explicito com transação controladada fora dele. É mais fácil.
Pense no UnitOfWork como um Command cuja execução é especial: é dentro de uma transação e num ambiente que controla concurrencia.

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Sérgio,

É nisso que eu queria chegar... Você injeta um IUnitOfWork no repositório. A minha dúvida é como é essa interface...

Algo do tipo resolveria, concorda?

Os Unit of Works de vocês tem algo a mais do que isso?

E aí tanto o Repositorio quanto o Unit of Work fica acoplado ao DAO? Por exemplo..

É por aí?

[]'s
Mauricio

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

MauricioAniche wrote:Sérgio,

É nisso que eu queria chegar... Você injeta um IUnitOfWork no repositório. A minha dúvida é como é essa interface...

Algo do tipo resolveria, concorda?

public interface IUnitOfWork { void add(Object o); void delete(Object o); void update(Object o); void persistAll(); }

Os Unit of Works de vocês tem algo a mais do que isso?

Esse é o padrão UnitOfWork tal como definido pelo Fowler. Na prática não encontro essa forma do padrão util.
Eu perfiro um versão um pouco diferente (que chamo de WorkUnit para não confundir).

abstract classs WorkUnit {

public abstract  String getWorkResource();
  public abstract void doLocks(WorkContext context);
  public abstract void doWork(WorkContext context);
}

class WorkUnitExecutor{ // ponto de invocação dos trabalhos

public void execute (WorkUnit wu){
               // faz queue da unidade conforme o recurso 
           
               WorkContext wc = new WorkContext (wu)
               wc.execute();
       }
}

class WorkContext {
     @Inject DAO realDAO;
     WorkDAO workDAO = new WorkDAO();

public void lockResource(String resource){
           // faz o lock do recurso. controla locks anteriores.
        // em caso de problema envia um OptimisticLockException.
      }

execute(){
           Transacion t= ...;
           // joga workDAO no thread
           try{
             t.begin() 
             this.wu.doLocks(this);
             this.wu.doWork(this);
             workDAO.commitTO(daoReal);
             
             t.commit();
          } catch (){
             t.rollback();
          } finally {
                 releaseLocks();
                 // retira workDAO do thread
          }
      }

}

// uso

TransferWorkUnit  wu = new TransferWorkUnit  ( // parametros como contas, valores etc..);
WorkExecutor.getInstance().execute(wu);

class TransferWorkUnit  extends WorkUnit  {

public void doWork(WorkContext wc){
         RepositoryA r = Repositories.getRepository(RepositoryA.class);

// faz algo com r
  }
}

A ideia é que existe um objetivo do tipo comando (o WorkUnit) cuja execução é controlada através de um contexto. Ele pode usar esse contexto para fazer lock de recurso para controlar concorrencia ( pois a do banco não é suficiente já que pode nem existir um banco...).

O contexto usa um DAO especial. Este dao recebe todos as ações mas não as executa, apenas as coloca numa lista. Só quando acontece o commit é que o DAO joga os comandos para um DAO real.

Aqui é extremamente importante que o Repositorio possa ser injetado com o DAO. O repositorio é obtido através de um Registry que olha um threadLocal pelo DAO que está valendo. O WrokContext manipula esse threadlocal para que o Repositorio seja injetado com o DAO "dummy" . Dentro do codigo do workunit que é o que o programador escreve não ha diferença nenhuma já que ele está proibido de usar o DAO , tem que usar o respositório sempre que mexe com regras de negocio.

No fim tudo é revertido para a forma original.
Vc perguntou como eu fazia...

O meu WorkDAO seria o equivalente ao UnitOfWork do Fowler.

E aí tanto o Repositorio quanto o Unit of Work fica acoplado ao DAO? Por exemplo..

class Repositorio { DAO _dao; // injetado Unit _unit; // injetado public void adiciona(Pedido p) { _unit.add(p); } public List<Pedido> PegaTodos() { return _dao.pegaTodos(); } } class UnitOfWork extends IUnitOfWork { DAO _dao; // injetado public void add(Object o) { _dao.save(o); } public void persistAll() { _dao.commit(); } }

Repare que o UnitOfWork é um buffer do DAO , ou seja, as acções são iguais aos do DAO mas elas não acontecem realmente até que ha o commit final. Ele é um DAO com um método commit().
Nessa estrutura realmente o Repositorio tem que ser injetado com o DAO certo, especialmente em operação que manipulam os dados dentro de uma transação. E o UnitOfWork tem que ser injetado com o DAO real
Não faz sentido o Repositorio ter um UnitOfWork porque o UnitOfWork é opcional. Num select vc não usa UoW.

A ideia seria mais ou menos assim :

Nota: a annotaçao @Inject é só para dizer que deve ser injetado. Não é uma especificação de como a injeção deve acontecer. Básicamente significa "obtenha isto de alguma forma"

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Oi Sérgio,

Nesse seu último exemplo, você passando UoWDAO pro repositório, essa interface deve conter também os métodos do DAO, de listagem, e tudo mais, concorda?

Estou com um projeto aqui chamado SmartCA, não me lembro da onde eu baixei, mas é um exemplo de DDD em .NET. Olha a abordagem dele, e me diga o que você acha.

public interface IUnitOfWorkRepository
    {
        void PersistNewItem(IEntity item);
        void PersistUpdatedItem(IEntity item);
        void PersistDeletedItem(IEntity item);
    }

public class Repository : OutrasInterfaces, IUnitOfWorkRepository {

private IUnitOfWork unitOfWork;

// aqui os metodos add() , remove() apenas chamam as funcoes do IUnitOfWork
      // e implementa os metodos de IUnitOfWorkRepository que realmente persistem os dados no banco.
      // aqui tb tem funcoes de listagem como FindBy() e etc...
        public void Add(T item)
        {
            if (this.unitOfWork != null)
            {
                this.unitOfWork.RegisterAdded(item, this);
            }
        }
    }

public interface IUnitOfWork
    {
        void RegisterAdded(IEntity entity, IUnitOfWorkRepository repository);
        void RegisterChanged(IEntity entity, IUnitOfWorkRepository repository);
        void RegisterRemoved(IEntity entity, IUnitOfWorkRepository repository);
        void Commit();
        object Key { get; }
        IClientTransactionRepository ClientTransactionRepository { get; }
    }

public class UnitOfWork : IUnitOfWork {

// aqui os metodos guardam as classes em colecoes, e no Commit(), elas passam a IEntity
       // para os IUnitOfWorkRepository, esses que realmente executam a persistencia
      
       // segue codigo do commit() para melhor entendimento
        public void Commit()
        {
            using (TransactionScope scope = new TransactionScope())
            {
                foreach (IEntity entity in this.deletedEntities.Keys)
                {
                    this.deletedEntities[entity].PersistDeletedItem(entity);
                    this.clientTransactionRepository.Add(
                        new ClientTransaction(this.key, 
                        TransactionType.Delete, entity));
                }

foreach (IEntity entity in this.addedEntities.Keys)
                {
                    this.addedEntities[entity].PersistNewItem(entity);
                    this.clientTransactionRepository.Add(
                        new ClientTransaction(this.key,
                        TransactionType.Insert, entity));
                }

foreach (IEntity entity in this.changedEntities.Keys)
                {
                    this.changedEntities[entity].PersistUpdatedItem(entity);
                    this.clientTransactionRepository.Add(
                        new ClientTransaction(this.key,
                        TransactionType.Update, entity));
                }

scope.Complete();
            }

this.deletedEntities.Clear();
            this.addedEntities.Clear();
            this.changedEntities.Clear();
            this.key = Guid.NewGuid();
        }
    }

Conseguiu entender? Essa implementação também é bastante interessante, não?

[]'s

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

MauricioAniche wrote:Oi Sérgio,

Nesse seu último exemplo, você passando UoWDAO pro repositório, essa interface deve conter também os métodos do DAO, de listagem, e tudo mais, concorda?

sim esqueci de dizer que UoWDAO implementa DAO

Estou com um projeto aqui chamado SmartCA, não me lembro da onde eu baixei, mas é um exemplo de DDD em .NET. Olha a abordagem dele, e me diga o que você acha.

É isso ai. Só achei estranho esta parte :

Se o unitOfWork é nulo o repositorio não faz nada ? .. meio estranho.
Por outro lado, quem chama o método Commit ? Não é o repositorio , certo ?
Logo o repositorio não precisa saber que existe um UoW , apenas o DAO. E o DAO é obrigatorio existir ou dá exception.

É que nesse exemplo em .NET não ha DAO e o UoW faz o papel tanto de UnitOfWork como de DAO.
Eu só acho que é melhor separar as resposabilidades. Caso contrário eu poderia escrever este codigo sem sentido

This message was edited 1 time. Last update was at 29/04/2008 16:45:03

Sérgio,

Essa discussão tá ficando interessante e me ajudando demais!

Só não entendi uma coisa, você falou que tem que separar as responsabilidades, mas você disse que UoWDAO implementa DAO, ou seja, UoW é um Unit of Work e também é um DAO? Você passa o DAO real (que foi injetado) para o UoW.. Não fica meio estranho você ter o DAO na camada de aplicação?

Não é tão casual assim separar as responsabilidades desses dois, né?!

[]'s
Mauricio

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

MauricioAniche wrote:Sérgio,

Essa discussão tá ficando interessante e me ajudando demais!

Só não entendi uma coisa, você falou que tem que separar as responsabilidades, mas você disse que UoWDAO implementa DAO, ou seja, UoW é um Unit of Work e também é um DAO?

ah! mas um DAO não é um UnitOfWork. Essa é a separação. Um Unit of Work tem mais responsabilidades. Ele tem que implementar commit(); É essa responsabilidade que o DAO não tem, nem deve ter.

Você passa o DAO real (que foi injetado) para o UoW.. Não fica meio estranho você ter o DAO na camada de aplicação?

Eu não o "tenho". E ele não está em lado nenhum. Eu apenas preciso de o injetar.
Repare que o uso do UoW como um DAO é um simplicifador. Vc é livre de criar o UoW com a interface que quiser. Contudo, em algum ponto, o DAO real será chamado. Então porque não dentro do commit() ?

Não é tão casual assim separar as responsabilidades desses dois, né?!

Não entendi o que quer dizer com esta frase. Separação de responsabilidade é o dia-a-dia. É o que separa sistemas bem feitos de gambiarras...

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Sérgio,

Sim, essa é a idéia, nada de gambiarras...

Então vamos ver se eu entendi... O Unit Of Work vai receber um DAO, meu Repositorio vai receber meu UoW. Meu UoW então vai ter que disponibilizar toda a funcionalidade do DAO para o repositorio... Imagine o seguinte caso... Tenho 2 repositorios... Clientes e Pedidos...

Repare que eles tem em comum apenas os métodos de persistência, mas na listagem cada um tem o seu. Vc sugere meu IUnitOfWork ter métodos do tipo FindBy(QueryObject qo), FindByPk(), e coisas do tipo ?

[]'s
Mauricio

Entusiasta Java Membro desde: 20/12/2007 18:33:07 Mensagens: 24 Offline

Sérgio,

Que é a idéia do NWorkSpace, do Nilsson, correto?

http://www.jaoo.dk/jaoo2006/articles/nworkspace.jsp

[]'s
Mauricio

Notícias, artigos e o maior fórum brasileiro sobre Java