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:

  1. que o processo chamador tem direito de acesso;
  2. abrir/fechar a transação;
  3. instrumentar o início/fim da transação;
  4. persistir no banco de dados as mudanças dos objetos do EF;
  5. fechar todos os contextos abertos para liberar o espaço.

Que tal? Vocês compram?