Façades e Singletons
Outro dia fiz um webcast sobre Entity Framework (EF). A idéia foi simples: apresentar os conceitos básicos do EF, os conceitos por traz do edm (Entity Data Model) e object context, e o como lidar com o EF numa arquitetura 3 camadas.
Utilizei como base um bom artigo do John Papa (ver), mas fiz questão de estendê-lo para incorporar um cenário que creio ser mais realista. Acrescentei as seguintes preocupações:
- Como garantir que objetos distintos trabalhem com um mesmo edm/contexto? É comum uma thread chamar mais de um objeto ou método de negócio que necessitam trabalhar com o mesmo contexto. Como evitar a ostensiva passagem de contextos através de argumentos simplificando a programação?
- Como garantir o uso de mais de um contexto/edm em uma mesma thread? É uma boa prática dividir seu modelo em sub-modelos. Um exemplo simples: é bom ter um sub-modelo de um contas a pagar e outro para o contas a receber. No entanto, um módulo gerencial pode precisar de ambos para calcular o estado financeiro da empresa. Para isto, necessitamos garantir que dois object contexts distintos trabalhem numa mesma transação.
Para lidar com estes problemas, minha sugestão é o uso coordenado de um façade e singletons. Explico:
Uma biblioteca implementa os singletons da thread. Assim, uma regra de negócio pede um contexto e a biblioteca o procura no dicionário da thread. Se não existir, o contexto é criado e inserido no dicionário da thread;
Ao façade cabem as missões de garantir:
- que o processo chamador tem direito de acesso;
- abrir/fechar a transação;
- instrumentar o início/fim da transação;
- persistir no banco de dados as mudanças dos objetos do EF;
- fechar todos os contextos abertos para liberar o espaço.
Que tal? Vocês compram?
