Bom dia!

Estou com uma duvida a respeito de como montar minha arquitetura usando o Entity Framework. Estou acostumado a Criar os projetos em 4 camadas (Acesso a dados, Negocio, Apresentação e Entidades). Estou começando a estudar o EntityFramework e removi minha camada de acesso a dados e criei um novo projeto com os mapeamentos do entity, o problema acontece que preciso referenciar na camada de apresentação o novo projeto para que a mesma entenda minhas entidades.

Gostaria de saber se existe alguma outra abordagem ou de algum modo separar as entidades das funções de acesso aos dados usando o entity.

Muito Obrigado!

Exibições: 254

Respostas a este tópico

Minha camada de negócio é provedora de interfaces de persistência, assim ela fica independente de como isto é feito. Entre a camada de visualização e a camada de persistência eu tenho uma outra camada chamada de "camada de aplicação" que é transversal as demais e fica como gestora das dependências. Vejo algumas arquiteturas que criam uma camada de IoC. Dessa forma sua camada conhece o domínio, solicita a camada de IoC a instância da dependência.

Yan,

Fiquei um pouco confuso com sua explicação.

Você quer dizer que, nessa outra camada de aplicação, você cria as classes necessárias que tem os fields referenciados na camada de persistência? Quero dizer, como se fosse um DTO, ou, um espelhamento tabela/repositório?

Também costumo utilizar interfaces junto com a camada de negócios. Assim a camada de negócios fica independente de como os dados são persistidos. Exatamente como você disse, através de injeção de dependência, podemos configurar a aplicação para trabalhar de forma flexível, com qualquer camada de acesso a dados pois ela terá que respeitar os contratos (interfaces).

Yan de Lima Justino disse:

Minha camada de negócio é provedora de interfaces de persistência, assim ela fica independente de como isto é feito. Entre a camada de visualização e a camada de persistência eu tenho uma outra camada chamada de "camada de aplicação" que é transversal as demais e fica como gestora das dependências. Vejo algumas arquiteturas que criam uma camada de IoC. Dessa forma sua camada conhece o domínio, solicita a camada de IoC a instância da dependência.

Fala Felipe, tranquilo?

Na verdade, você continua tendo uma camada de acesso à dados. Só que quem faz todo o trabalho é o Entity. O que você pode fazer é implementar um padrão de projeto chamado Repository. A grosso modo, o objetivo deste padrão é abstrair o acesso a dados, como o entity já faz isso, a implementação não será trabalhosa. Tem bastante coisa pela internet sobre como implementar este padrão com Entity.

Em termos de como ficaram os projetos na sua solution, eu particularmente, colocaria "o entity" em um projeto separado. Neste projeto criaria as classes repositório também. Um outro projeto com a aplicação e outro com as regras de negócio.

Se usar Injeção de Dependência, fica melhor ainda. Mas só recomendo se você conhecer este conceito...

Felipe, boa tarde!

Eu costumo criar uma camada de acesso a dados na qual terá todo código concreto do EF e na camada de domínio eu crio uma abstração do que será a minha persistência. Dessa forma o domínio não sabe como os dados serão persistidos e toda a infraestrutura disso fica na camada de acesso a dados.

Caso ainda esteja precisando, eu poderia fazer um exemplo e postava para você.

Um abraço.

Se você trabalhar com COde First poderá ter suas entidades separadas da cada de acesso a dados normalmente.

RSS

© 2019   Criado por Ramon Durães.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço