Modelli per l'utilizzo di EntityFramework?

Question

Quali sono i modelli alternativi di utilizzo per Entity Framework?

Alcuni che conosco sono:

1. " Plain " EntityFramework - alias Unity of Work

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

2. Modello di repository

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

3. Cos'altro?

Answer 1

Un buon libro da guardare è " Modelli di architettura di applicazioni enterprise " .

Lì passa attraverso alcuni schemi per il recupero / mappatura di dati come DTO, Unità di lavoro, modello di archivio ecc ... Forse qualcosa potrebbe essere utile insieme a Entity Framework. Dovrei dare un'occhiata.

Answer 2

Rispondo alla tua domanda in base al presupposto che stai utilizzando Entity Framework direttamente nell'interfaccia utente / controller / servizi.

È stato dimostrato che l'uso di qualsiasi ORM, incluso EF, direttamente nell'interfaccia utente / nei controller / nei servizi causerà molti problemi in futuro. Inoltre, rende così difficile, se non impossibile, testare l'unità della tua applicazione.

Il secondo approccio, ad esempio "Modello implementa il repository" è anche sbagliato secondo me, perché Modello e Repository hanno responsabilità diverse e si basano su "Responsabilità singola" parte dei principi SOLIDI non dovresti unire i due concetti insieme. Anche se si desidera utilizzare il modello di oggetti attivi nel modello, che non è consigliabile, è necessario separare il modello dall'ORM in uso.

La soluzione migliore e più consigliata è quella di avere un'interfaccia come IRepository o IRepository con i membri di base come suggerisce il modello. qualcosa come:

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);
}

Si noti che alcuni repository credenti di persone non dovrebbero restituire IQueryable. Inoltre, puoi prendere in considerazione l'utilizzo di ISpecification anziché di espressioni e lambda.

dovresti implementare l'interfaccia IRepositoy per la maggior parte delle tue entità. Usando questo approccio puoi anche deridere i tuoi repository durante la scrittura di unit test. In produzione, è necessario utilizzare un provider Ioc come Unity, Ninject, Linfu, Catsle e così via. È inoltre possibile beneficiare dell'implementazione di localizzatore di servizi comuni di Microsoft per evitare l'accoppiamento a un framework IoC specifico.

Ai vecchi tempi, avevo un'interfaccia di accesso ai dati che era stata impiantata per uno specifico dominio aziendale o un servizio. Uno dei problemi con questo approccio è che potresti ritrovarti con un codice duplicato in diversi servizi di accesso ai dati se tieni traccia del tuo codice sorgente e alla fine lo farai.

Answer 3

Usiamo un codice simile a quello che hai nella tua unità di lavoro esempio.

Ciò che facciamo inoltre è mappare gli oggetti su Data Transfer Objects.

Answer 4

Ci sono molti articoli sull'argomento, ma l'elenco sarà ridotto sostanzialmente se ne desideri uno buono. Questo articolo dalla rivista MSDN è abbastanza buono, anche se si occupa specificamente di applicazioni di livello n. Ma dal momento che non dici quello che stai costruendo, forse ti aiuterà.

Answer 5

LINQ 2 SQL può essere un'alternativa. Ecco un articolo Iniezione delle dipendenze con Unity e Linq to SQL DataContexts

UNITY - http://unity.codeplex.com/