NHibernate vs. EF 4.1+

Question

Sto cercando di decidere i pro ei contro dei 2 ORM principalmente in quest'area.

1. Compatibilità con SQL Server 2008 R2 & 2012.
   • Questo è molto importante in quanto ci semplicemente non hanno le risorse per eseguire il debug di scarso supporto della tecnologia stack MS esistente.
   • Anche pianificare in anticipo dal 2012 è praticamente fuori e i piani per migrare ad esso sono a posto.
2. supporto per .NET 4.0 e 4.5 (imminente)
   • Ancora una volta molto importante per più o meno lo stesso motivo di cui sopra.
3. Gestione transazioni e suggerimenti tabella es. forcescan forceseek, leggi non accettato.
   • Un sacco di volte il Query Optimizer fa bene il suo lavoro, altre volte voglio la flessibilità per dirgli cosa fare.
4. supporto per la conversazione, l'auto monitoraggio allegare & staccare
   • Questo è un po 'fondamentale. Detesto mantenere la sessione aperta per un periodo prolungato. Soprattutto in ambiente di calcolo distribuito/web farm.
5. Capacità di gestire il primo sviluppo del codice, creare e aggiornare lo schema senza distruggere i dati.
   • EF 4.1 sembra essere carente a questo proposito, sebbene 4.3 sia il salto e legato meglio. Mi piace anche l'annotazione dei dati meglio di classi di mappatura separate in NH. La ragione è che voglio essere in grado di inviare la classe e da lì essere in grado di creare un modello di persistenza senza ampliare il metodo per le classi di mapping.
6. Supporto per modello IRepository
7. Supporto per LINQ
   • Un po 'legato al (6), voglio davvero un buon supporto per LINQ. Non voglio sviluppatori di impazzire con l'attuazione di livello inferiore e ottenere noi stessi bloccati a un particolare ORM
8. prestazioni
9. supporto per le attività CRUD rinfusa, senza dover caricare i dati nel livello di applicazione. Per esempio. Voglio incrementare tutte le righe in una colonna di una tabella specifica di 1. Non voglio caricarlo in memoria e incrementare le righe una alla volta. Questo sarebbe pazzesco per un'operazione così semplice. Linq2Sql era solito avere Magiq per gestire questo genere di cose, cosa hanno NH e EF?
10. Caching, caricamento bisognoso, caricamento lento, proprietà di navigazione.
    • Lasciatemi essere sincero, odio queste cose quando sono implicite. La ragione è che è difficile distinguere ciò che è memorizzato nella cache, stantio da ciò che è nuovo. In EF di solito trascino tutte le proprietà di navigazione, perché non voglio che queste proprietà vengano caricate con la top 5, perché è quello che richiede l'operazione corrente, ma più avanti nel flusso un altro sviluppatore tenta di fare un conteggio che sarà impreciso.
    • Quindi la mia politica personale - tutti i SOA devono essere apolidi a meno che non vi sia una buona ragione altrimenti. Se hai bisogno di referenziare i dati, prendi dalla persistenza. Sarà più lento ma il codice sarà più leggibile e flessibile.
    • Analogamente per la memorizzazione nella cache. È abbastanza complesso in quanto è in ambiente distribuito, voglio che tutto il caching sia molto esplicito. Se uno sviluppatore vuole eseguire il codice contro la cache, dovrebbe farlo, non il codice contro l'ORM, e farlo apparire come se stesse estraendo dati dalla persistenza, mentre in realtà sta ottenendo dati obsoleti.
    • Ora la domanda è, NHibernate ha qualche concetto/astrazione che renderebbe il caricamento in cache, desideroso/pigro molto più esplicito di quello attualmente disponibile in EF. In questo caso non mi interessa molto della facilità di sviluppo, mi interessa di più della chiarezza e esplicita.

Inoltre non mi interessa tanto per OSS vs argomento proprietarie. La squadra non può permettersi il tempo di sbirciare sotto il cofano e iniziare a scherzare con il codice di altre persone. Mi interessa di più dell'angolo "funziona" di qualsiasi altra cosa.

Answer 1

Si potrebbe utilizzare bltoolkit;) ->http://www.bltoolkit.net/Doc.Linq.ashx

Basta prendere 2 minuti per leggere questo ->http://www.bltoolkit.net/Doc.LinqModel.ashx

ma in breve

• estremamente buon supporto Linq
• operazioni DML (9)
• ottimo rendimento/supporto bulk
• grande generato Sql
• supporto enum ;-)
• senza lazy loading/tracking entità/speciale caching magia, ora queste cose che di solito causano problemi
• Nessuna caratteristica magici -> meno astrazione -> meno perdite -> meno problemi -> curva di apprendimento più piccolo

btw lo fa nr 3, che ha attributi TableFunction & TableExpression per sostenere valori di tabella UDF, suggerimenti, e altri in giro per decorazioni da tavola. in modo da poter scrivere i propri metodi di estensione da utilizzare per i LINQ dichiarazioni ad esempio

[TableExpression("{0} {1} WITH (TABLOCK)")] 
public Table<T> WithTabLock<T>() 
    where T : class 
{ 
    return _ctx.GetTable<T>(this, ((MethodInfo)(MethodBase.GetCurrentMethod())).MakeGenericMethod(typeof(T))); 
} 

e poi

using (var db = new TestDbManager()) 
{ 
    var q = 
     from p in new Model.Functions(db).WithTabLock<Parent>() 
     select p; 

    q.ToList(); 
} 

Esempio operazione DML

db.Employee 
    .Where(e => e.Title == "Spectre") 
    .Set(e => e.Title, "Commander") 
    .Update(); 

Answer 2

Non vuoi nessuno dei due. Non sarai in grado di specificare suggerimenti di tabelle arbitrarie, e non sarà affatto flessibile come vuoi che sia.

Se tutti questi sono requisiti, non ci sono ORM sul pianeta che li incontreranno.

EDIT:

Sulla base della sua commento. nHibernate ti darà la massima potenza, ma a costo di una maggiore complessità nella configurazione del tuo modello. Ci sono alcuni strumenti che potrebbero aiutare, ma ognuno ha i suoi lati positivi e negativi.

EF è più facile da configurare e utilizzare, ma meno potente. L'ibernazione è l'opposto. Devi scegliere tra potenza e complessità.

BTW, per quanto riguarda le operazioni di massa e quali no, è possibile emettere semplicemente SQL direttamente dal framework per tali operazioni. Oppure chiama un proc memorizzato.

Answer 3

Prima di tutto, preferisco NHibernate sotto vari aspetti. Entity Framework manca qualcosa anche nella versione 5.0.

1. è molto facile aggiungere un nuovo tipo di NHibernate, quindi se SQL Server 2012 ha nuovi tipi è possibile implementare il relativo dialetto/fornitore, ma la comunità è sempre al lavoro
2. So che la squadra NH è lavorando sul supporto di FW 4.5, EF supports dal 5.0
3. Usando NH si può fare tutto quello che vuoi
4. NH supporta il metodo di unione per ricollegare un'entità, EF anche
5. EF non supporta le convenzioni di denominazione, NH fa, sto anche scrivendo un auto mapper basato su DataAnnotations, here il collegamento alla versione precedente, attendere 2 settimane per il nuovo
6. Utilizzando NH o EF è possibile implementare il livello dati con i modelli di repository e unità di lavoro, devo rilasciare anche questo pacchetto su NuGet
7. EF supporta pienamente LINQ, NH non ma è possibile applicare patch con un'estensione point
8. Penso che le prestazioni siano sullo stesso livello, NH supporta meglio la cache di livello secondario, quindi è facile prevenire i colpi al database
9. NH ha un batch migliorato support, non so su EF (specialmente il 5.0)
10. NH gode di una migliore attuazione dei punti di estensione, in modo da proxy/caching/registrazione sono potente di EF, ma in EF è possibile scrivere un wrapper per ottenere quello che ti serve

alla fine, con NH è più facile implementare pattern DDD, perché la mappatura è più flessibile.

Answer 4

solo per aggiungere ad altre risposte ...

Ricardo Peres ha scritto un ottimo, confronto imparziale di NHibernate e Entity Framework pochi giorni fa. Potrebbe aiutarti nella tua ricerca.

Lo si può trovare qui: http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx

Answer 5

Mentre ho scritto su alcuni di questi temi in another question, credo che valga la pena rispondere a questo punto per punto.

1. Entrambi sono compatibili con tutte le versioni di SQL Server
2. entrambi sono compatibili con .NET 4.x. NH ha ancora il targeting per 3.5, che non è un problema.
3. Entrambi hanno la gestione delle transazioni. Né supporta gli hint di query nei linguaggi di query nativi, ma entrambi consentono di utilizzare SQL.
4. Entrambi consentono di riattaccare entità disconnesse. Personalmente non penso che questa sia una buona pratica (preferisco passare DTO in giro)
5. La migrazione dello schema è più matura e flessibile in EF. La mappatura è molto, molto meglio in NH. Ha il supporto per la mappatura con attributi, che è molto più potente dell'equivalente di EF, che troverai rapidamente non supporta anche elementi di base (come specificare la precisione di un campo decimale)
6. Puoi implementare il tuo repository in cima a uno a scelta.
7. Entrambi supportano LINQ. EF supporta una gamma più ampia di query, al costo di generare a volte quelle estremamente inefficienti. Non dovresti sminuire le tue pratiche di sviluppo; ogni metodo di ricerca ha i suoi vantaggi e un buon sviluppatore dovrebbe conoscere le opzioni.
8. Le prestazioni sono generalmente migliori con NH a causa della sua flessibilità di mappatura e supporto per istruzioni di batching, memorizzazione nella cache e DML
9. EF non supporta le operazioni bulk (DML).NH fa, utilizzando INSERT/UPDATE/DELETE che sono molto simili a quelle di SQL, ma il modello di oggetti (ad esempio, è possibile specificare le condizioni utilizzando la sintassi del punto, invece di esplicito join)
10. • EF non supporta memorizzazione nella cache, punto. Ci sono alcuni campioni non supportati che non sono pronti per la produzione. Tutta la memorizzazione nella cache in NHibernate è esplicita (si specificano le entità, le raccolte e le query che si desidera memorizzare nella cache, per quanto tempo, ecc.). Supporta cache distribuite come memcached, quindi può occuparsi anche dei dati cache stantii.
    • Entrambi consentono di caricare esplicitamente riferimenti e raccolte. NH ha, a mio parere, un design proxy migliore, che non inquina il tuo modello con FK (questo è un argomento lungo, puoi postare una domanda successiva se vuoi). E come al solito, si ha più flessibilità quando si specifica come ogni relazione deve essere caricata.

In breve: NH è più flessibile e più prestanti, giù le mani. EF offre un migliore supporto per la migrazione, una curva di apprendimento leggermente più semplice e un provider LINQ più completo.