Padrões para a utilização EntityFramework?

Question

O que é padrões alternativos de utilização para o Entity Framework?

Alguns eu sei são:

1. "Plain" EntityFramework - aka Unidade de Trabalho

   using (Data.Model c = new Data.Model())
   {
       var z = c.Users.Where(x=>x.Name=='John');
   }
   
   

2. padrão Repository

   //Model implements IRepository
   User user = Model.Instance.Get<User>(u => u.Name == "John");
   

3. O que mais?
4. ?

Answer 1

Um bom livro para olhar é de Martin Fowler " Os padrões de arquitetura de aplicações empresariais ".

Lá, ele passa por alguns padrões de dados recuperação / mapeamento como DTOs, Unidade de trabalho, repositório padrão etc ... Talvez algo poderiam estar juntos útil com o Entity Framework. Eu teria que dar uma olhada nisso.

Answer 2

Eu respondo sua pergunta com base no pressuposto de que você está usando o Entity Framework diretamente no seu UI / controller / Serviços.

Está provado que o uso de qualquer ORM, inclusing EF, diretamente em seus UI / Controladores / Serviços irá causar uma série de problemas no futuro. Além disso, torna-se tão difícil, se não impossível, para teste de unidade a sua aplicação.

A segunda abordagem ou seja, "implementa modelo de repositório" também está errado na minha opinião, becuase modelo e Respositories têm diferentes responsiblities e baseado em parte "Single Responsibilty" de princípios sólidos que você não deve fundir os dois conceitos juntos. Mesmo se você quiser usar padrão de objetos ativos em seu modelo, que eu não recomendo, é necessário dissociar seu modelo na ORM que você usa.

A melhor ea solução mais recomendada é ter uma interface como IRepository ou IRepository com os membros muito básicos como o padrão sugere. algo como:

Interface IRepository<T> where T:class
{
    void Insert(T entity);
    void Update(T entity);
    void Delete(T entity);

    // if you don't want to return IQueryable
    T FindById(object id);
    IEnumerable FindXXXXX(params)

    // if you prefer to return an IQueryable
    IQueryable<T> Find(Expression<Func<T, bool>> predeicate);
}

Note que alguns poeple beleive Repositories não deve retornar IQueryable. Além disso, você pode considerar o uso ISpecification em vez de expressões e lambda.

você precisa implementar a interface IRepositoy para a maioria de suas entidades. Usando essa abordagem, você também pode zombar de seus repositórios ao escrever testes de unidade. Na produção, você precisa usar um provedor Ioc como Unidade, Ninject, Linfu, Catsle e etc. você também pode beneficiar com a implementação localizador de serviço comum da Microsoft para evitar o acoplamento de um quadro IoC específi.

Nos velhos tempos, eu costumava ter uma interface de acesso a dados que foi impleneted para um domínio de negócio específico ou um serviço. Um dos problemas com esta abordagem é que você iria acabar com código duplicado em diferentes serviços de acesso a dados se você manter o controle de seu código-fonte e você acabará.

Answer 3

Nós usamos um código semelhante ao que você tem em sua unidade de exemplo de trabalho.

O que fazemos além é mapear objetos para Transferência de Dados Objects.

Answer 4

Há muitos artigos sobre o assunto, mas a lista será reduzida substancialmente se quiser uma boa. Este artigo da MSDN Magazine é muito bom, embora ele lida especificamente com aplicações n-tier. Mas desde que você não diga que você está construindo, talvez ajude.

Answer 5

LINQ 2 SQL pode ser uma alternativa. Aqui está um artigo Dependency Injection com Unidade e Linq to SQL DataContexts

A UNIDADE - http://unity.codeplex.com/