Usando Entity Framework em aplicações n-camadas do lado do cliente

A figura abaixo exibe uma arquitetura básica para aplicações clientes usando o Entity Framework (é claro que é apenas uma sugestão de arquitetura).

Observe que a camada de interface (Windows Forms/WPF) não efetua chamadas diretamente à camada de acesso a dados e que entre elas existe a camada de negócios, de forma que a interface se comunica com a camada de negócios e a camada de negócios se comunica com a camada de acesso a dados.

O ObjectContext atua como uma ponte entre o Entity Framework e as classes de entidades(Entity Classes) que você usa na sua aplicação.

Temos aqui um detalhe importante que ocorre na prática: geralmente você instancia um ObjectContext em um Windows Forms e faz as consultas e efetua as alterações nos objetos diretamente, e, estas tarefas não fazer partem de uma camada de interface que deve tratar apenas com a interação com o usuário.

Você poderia dizer que estas tarefas fazerm parte da camada de acesso a dados, mas como estas ações não interagem diretamente com o banco de dados, você também poderia considerar que elas seriam tarefas da camada de negócio.

E agora ? como ficamos ?

Uma sugestão para sair desse impasse e tornar mais claras as responsabilidades (ou seria tornar menos confusas) seria criar uma mais uma camada que atuaria como uma ponte entre a camada de interface a camada de negócio e que conteria o ObjectContext:

Esta camada intermediária conteria o ObjectContext e criaria as instâncias do ObjectContext usando-as para efetuar as consultas no Entity Data Model (EDM), salvar alterações nos objetos e realizar qualquer interação com os objetos que o ObjectContext estiver gerenciando. Esta camada intermediária dependeria de uma classe genérica que iria executar qualquer consulta e comando efetuando o tratamento de exceção.

Fica então esta sugestão que pode servir como base para uma arquitetura mais refinada(através da sua expertise) e adequada a realidade do seu ambiente.

Definindo as camadas

E por falar em camadas vamos considerar como efetuar a definição delas quando o Entity Framework esta sendo usado em uma aplicação do lado do cliente.

Para começar que fique bem claro que ninguém é obrigado a trabalhar com camadas, mas que esta é uma boa prática que vai facilitar a organização do seu projeto de forma que usar projetos separados para tipos de lógicas diferentes é a forma preferida de manter as 'coisas' organizadas.

No caso de um projeto Windows Forms que usa o Entity Framework podemos fazer essa separação da seguinte forma:

1- O formulário Windows teria a lógica de interação com o usuário e seria a camada de interface;

2- O EDM, seus objetos de entidades e a lógica relacionada com os objetos conteria a lógica do negócio e poderia ser considerado como uma camada de negócios;

3- O Entity Framework poderia ser definido como o componente que cuidaria da lógica de acesso a dados fazendo parte portanto da camada de acesso a dados;

Volto a frisar que esta separação não é rigida e que o entendimento de como efetuar a separação das camadas pode variar de desenvolvedor para desenvolvedor. Dessa forma na hora de separar o que pertence a camada de acesso a dados e o que pertence a camada de negócios podem ocorrer diferenças.

No caso da utilização do Entity Framework para alguns desenvolvedores somente o código que interage diretamente com o banco de dados pertence a camada de acesso a dados, já para outros, o código que é responsável para consultar e retornar os dados também pertence a camada de acesso a dados. (Quando você escreve código para consultar o Entity Data Model você não está interagindo diretamente com o banco de dados, é o Entity Framework que faz essa interação)

Quanto a utilização do Windows Forms e aplicações WPF(Windows Presentantin Fundation) parece que não há dúvidas, eles fazem parte da camada de interface e são candidados perfeitos para usar o Entity Framework diretamente, pois possuem um acesso completo ao .NET Framework ; As aplicações Silverlight embora sejam aplicações do lado do cliente apresentam um problema: o runtime do Silverlight não inclui o Entity Framework ou o ADO .NET e dessa forma dependem de web services para o acesso aos dados.

E estamos conversados...

Eu sei é apenas Entity Framework, mas eu gosto...

Referências:

José Carlos Macoratti