Organizando sua camada de acesso a dados

5

Estou usando o Entity Framework como meu ORM em um aplicativo ASP.Net. Eu tenho meu banco de dados já criado, então acabei gerando o modelo de entidade dele. O que é uma boa maneira de organizar arquivos / classes na camada de acesso a dados. Meu modelo de estrutura de entidade está em uma biblioteca de classes e eu estava planejando adicionar classes adicionais por entidade (por exemplo, tabela de banco de dados) e colocar todas as consultas relacionadas a essas tabelas em suas respectivas classes. Não tenho certeza se essa é uma abordagem correta e, em seguida, onde estão as consultas que exigem dados de várias tabelas? Estou completamente errado em organizar meus arquivos com base em entidades / tabelas e devo organizá-los com base em áreas funcionais.

    
por nighthawk457 30.11.2011 / 00:18
fonte

2 respostas

2

No projeto em que estou trabalhando agora, estamos usando o ASP.NET MVC e o Entity Framework 4.1. Também tivemos um banco de dados primeiro, mas seguimos com a idéia de usar os objetos POCO gerados a partir dos modelos T4 baseados em DBSet.

Em nosso projeto, temos um assembly chamado business, que possui um namespace de dados. Dentro deste namespace é onde o DBContext e o POCO gerado estão vivos. Nós não tocamos nisso uma vez que o acesso a dados tenha sido criado. Agora, além disso, temos um conjunto de repositórios que estamos usando; 1: execute as necessidades básicas de CRUD e 2: crie e entregue objetos de transferência de dados personalizados até o front end.

No front end, é onde estamos usando as anotações de dados nos DTOs personalizados ou em ViewModels personalizados para necessidades específicas. Nossa suposição é que devemos validar os dados provenientes do front end o mais rápido possível e depois repassar os modelos limpos para os repositórios. Nós não estamos realmente muito preocupados com o rastreamento de mudança de entidade ou algo assim para a estrutura de entidade, desde que economizemos e puxe com sucesso.

Até agora, isso funcionou para nós. Espero que isso ajude você e boa sorte em seu projeto.

    
por 30.11.2011 / 04:09
fonte
1

Aqui estão algumas ideias que vi e usei no & trabalho anterior.

  • Crie um projeto separado como "nome do projeto" .Data

  • Crie classes parciais de suas classes EF. Adicionar funções Get estáticas e uma função Save derivada de uma entidade base que herda de EntityObject

  • Usando um padrão como Unidade de trabalho e armazenando o ObjectContext no HTTPContext para manipular suas conexões.

link

link

    
por 30.11.2011 / 02:41
fonte