Unity of work
Tudo pessoal?
Outro dia uma amigo me questionou sobre a utilidade do padrão Unity of Work (para facilitar, chamarei de UoW), na visão dele, o padrão não faz sentido e teria pouca utilização. Será que não tem nenhum valor? Para não respondê-lo por e-mail, resolvi postar a resposta.
Segundo Martin Fowller o padrão UoW é definido como:
Mantains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
em tradução livre:
Mantém uma lista de objetos afetados por uma transação de negócio, coordena a efetivação das mudanças e soluciona problemas de concorrência.
Para facilitar a compreensão do UoW, trazendo um pouco para a realidade de muitos, imagine o processo de negócio de emissão de uma nota fiscal (processo extremamente simplificado):
O processo de negócio somente será efetivado, se as três etapas forem concluídas. Como resolvemos este tipo de situação?
Geralmente abre-se uma transação no banco de dados, e se todas as etapas forem concluídas com sucesso, efetivamos a transação, caso contrário, abortamos, ou seja, voltamos ao estado anterior a transação.
O UoW é o cara que abre a transação, efetiva ou aborta, só que trabalhamos com o controle dos objetos (quais foram alterados, quais foram inseridos, excluídos , etc..).
Em um modelo orientado a objetos do nosso problema, a nota fiscal é um objeto, quando emito uma nota, no final das contas, instanciamos um objeto nota e incluímos o estado desejado (número da nota, data de emissão, lista de produtos (outro objeto),etc..) , portanto, a nota torna-se um novo objeto passível de ser persistido no banco de dados.
Se for uma alteração, basicamente retornamos os dados do banco, preenchemos um objeto do tipo nota, alteramos o estado do objeto, e este, posteriormente é persistido no banco. Com a exclusão, o processo é similar. Conseguiram ligar a expressão “Mantém uma lista de objetos afetados por uma transação de negócio” , com o exemplo exposto? Em nosso exemplo, teríamos outros objetos que serão gerenciados pelo UoW, e por ele conhecer todos, e os respectivos estados, consegue saber se houve algo errado, e abortar, se necessário.
Para a criação de UoW, Fowller em seu artigo sugere a seguinte interface:
Sacaram onde o objeto nota fiscal poderia ser incluso em cada situação?
Outro ponto importante, e faz parte da definição do UoW, é o controle de concorrência, que é outro assunto extremamente complicado e extenso, mas posso citar um exemplo:
Imagine duas pessoas, uma sem conhecimento da outra, alterando dados de um mesmo cliente, o que fazer no momento da persistência? Há algumas técnicas, como o bloqueio pessimista, ou seja, no momento que eu resgatar um cliente eu bloqueio este cliente, impedindo que qualquer outro o altere, ou , bloqueio otimista, onde faço a checagem se houve alguma alteração no momento da persistência. Enfim, implementar tudo isto não é algo tão trivial, e como o conceito padrão de projeto, é a solução para um problema recorrente, podemos imaginar que alguém já implementou isto, correto? Com certeza, vejamos alguns exemplos:
-
NHibernate, um ORM opensource bem conhecido: No NHibernate, temos o objeto Session, qual a função do Session? Ele abre a transação e monitora todos os objetos utilizados no processo de negócio.
-
Entity Framework, ORM desenvolvido pela Microsoft: No Entity Framework, temos um objeto similar ao Session do NHibernate, o datacontext.
-
DataSet do .Net Framework: Um dataset, é um banco em memória e desconectado do banco de dados, trocando em miúdos, podemos retornar dados de um banco, alteramos, incluímos dados em memória e solicitamos que as alterações sejam persistidas.
Conclusão
Não feche os olhos aos padrões, entendê-los é importante, fazem parte do nosso dia-a-dia, e são a melhor forma de reuso de conhecimento gerado a partir do sofrimento de muitos.
Fala sério, também fica bonito em uma reunião técnica, rs…
Quer aprender mais?
[]’s
Fabio Margarito