Quali sono i modelli alternativi di utilizzo di Entity Framework?Modelli per l'utilizzo di EntityFramework?
Alcuni che conosco sono:
"Plain" EntityFramework - aka Unità di lavoro
using (Data.Model c = new Data.Model())
{
var z = c.Users.Where(x=>x.Name=='John');
}
Pattern Repository
//Model implements IRepository
User user = Model.Instance.Get<User>(u => u.Name == "John");
Un buon libro da guardare è il numero "Patterns of enterprise application architecture" di Martin Fowler.
Esegue alcuni schemi per il recupero/mappatura di dati come DTO, Unità di lavoro, modello di repository, ecc. Forse qualcosa potrebbe essere utile insieme a Entity Framework. Dovrei dare un'occhiata a questo.
Utilizziamo codice simile a quello che hai nell'esempio di unità di lavoro.
Quello che facciamo in aggiunta è mappare oggetti a oggetti di trasferimento dati.
Ci sono molti articoli sull'argomento, ma la lista si ridurrà sostanzialmente se si desidera uno buono. This article from MSDN Magazine è piuttosto buono, sebbene si tratti in particolare delle applicazioni di livello n. Ma dal momento che non dici quello che stai costruendo, forse sarà d'aiuto.
LINQ 2 SQL può essere un'alternativa. Ecco un articolo Dependency Injection with Unity and Linq to SQL DataContexts
UNITY - http://unity.codeplex.com/
Rispondo alla tua domanda basato sul presupposto che si sta utilizzando Entity Framework direttamente nelle vostre UI/Controller/servizi.
È stato dimostrato che l'utilizzo di qualsiasi ORM, incluso EF, direttamente nell'interfaccia utente/controller/servizi causerà molti problemi in futuro. Inoltre, rende difficile, se non impossibile, testare la tua applicazione.
Il secondo approccio, ad esempio "repository di implementazioni di modello", è anch'esso errato, poiché Model e Respository hanno responsabilità diverse e sulla base della parte "Single Responsibility" dei principi SOLID non è necessario unire i due concetti. Anche se si desidera utilizzare il modello di oggetti attivi nel modello, che non è consigliabile, è necessario disaccoppiare il modello dall'ORM che si utilizza.
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 del tipo:
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 di file beleive non dovrebbero restituire IQueryable. Inoltre, puoi considerare l'utilizzo di ISpecification invece di espressioni e lambda.
è necessario implementare l'interfaccia IRepositoy per la maggior parte delle entità. Usando questo approccio puoi anche prendere in giro i tuoi repository durante la scrittura dei test unitari. In produzione, è necessario utilizzare un provider di Ioc come Unity, Ninject, Linfu, Catsle e così via.è inoltre possibile trarre vantaggio dall'implementazione del servizio di localizzazione comune di microsoft per evitare l'accoppiamento con un framework IoC specifico.
In passato avevo un'interfaccia di accesso ai dati che era stata importata per uno specifico dominio aziendale o servizio. Uno dei problemi con questo approccio è che si finirebbe con codice duplicato in diversi servizi di accesso ai dati se si tiene traccia del proprio codice sorgente e alla fine.
Consiglierei di cambiare il titolo della domanda perché confonde un po '. Il titolo riguarda come utilizzare Entity Framework e l'intera discussione sulle alternative (ad esempio NON usarlo) –
in realtà no. Sto cercando di capire come utilizzare esattamente EF. Intendo dire che non ho bisogno di alternative per EF, ho solo bisogno di un modo possibile di usare diversi pattern basati su EF. – bug0r