Entity Framework 4 vs NHibernate [chiuso]

Si è parlato molto della prima versione di Entity Framework sul web (anche su stackoverflow) ed è chiaro che non è stata una buona scelta quando abbiamo già alternative migliori come NHibernate. Ma non riesco a trovare un buon confronto tra Entity Framework 4 e NHibernate. Possiamo dire che oggi NHibernate è il leader tra tutti gli ORM .NET, ma possiamo aspettarci che Entity Framework 4 sostituisca NHibernate da questa posizione. Penso che se Microsoft ha davvero inserito ottime funzionalità in EF4, può dare una buona concorrenza a NHibernate in quanto ha l'integrazione con Visual Studio, più facile da lavorare e la preferenza è sempre data ai prodotti MS nella maggior parte dei negozi.

EF4 ha una risposta immediata per quanto riguarda lo sviluppo a più livelli, in "entità di auto-monitoraggio". Nessuno ha rilasciato un codice simile per NHib.

NHib ha molte caratteristiche che non sono state menzionate come parte di EF4. Questi includono l'integrazione della cache di secondo livello. Ha anche una maggiore flessibilità nella mappatura dell'ereditarietà, una migliore integrazione con processi memorizzati / funzioni di database / SQL personalizzati / trigger, supporto per le proprietà delle formule e così via. IMO è fondamentalmente solo più maturo come ORM.

Aggiornamento: non ho utilizzato Entity Framework dalla versione 4.0, quindi la mia risposta può essere obsoleta. Sto ancora usando NH o puro ADO .NET nei miei progetti. E non voglio nemmeno guardare alle novità di EF dalla 4.0, perché NH funziona perfettamente.

In realtà è abbastanza facile confrontarli quando li hai usati entrambi. Ci sono alcune serie limitazioni con EF4, posso citarne alcune che ho riscontrato da solo:

Problemi EF4:

• Eager Caricamento e modellazione del risultato : EF4 sistema di caricamento desideroso (Include ("Path")) genera SQL improprio, con JOIN in loop, che eseguiranno migliaia (non letteralmente) di tempo più lentamente per relazioni molti-a-molti quindi SQL scritto a mano (è effettivamente inutilizzabile).
• Materializer non può materializzare entità associate : se puoi pensare di poter superare il problema precedente fornendo la tua query SQL, ti sbagli. EF4 non può materializzare (mappare) entità associate dalla query SQL JOIN, può caricare solo dati da una tabella (quindi se hai Order.Product, SELECT * FROM order LEFT JOIN Product inizializzerà solo l'oggetto Order, Product rimarrà nullo, pensato che tutti i dati necessari vengano recuperati nella query per iniziarlo). Questo può essere superato utilizzando l'add-on della community di EFExtensions, ma il codice che dovrai scrivere per questo è davvero brutto (ho provato).

• Entità di auto-tracciamento: Molti dicono che le entità di auto-tracciamento sono interessanti per lo sviluppo a più livelli, inclusa la risposta principale in questo thread. Anche se non li ho nemmeno provati, posso dire che non lo sono.Ogni input può essere falsificato, non puoi semplicemente prendere le modifiche che l'utente ti invia e applicarle al database, perché non fornire dati diretti all'utente accesso alla base quindi? In qualsiasi modo dovrai caricare i dati che l'utente sta per cambiare dal DB, controlla che esista | non esiste fare i controlli dei permessi ecc ecc. Non puoi fidarti dell'utente sullo stato dell'entità che sta inviando al server, lo farai comunque è necessario caricare questa entità dal DB e determinarne lo stato e altre cose, quindi questa informazione è inutile, così come le entità Self-Tracking a meno che non si faccia un sistema privato di fiducia a più livelli per uso interno, nel qual caso forse si potrebbe dare semplicemente Accesso al DB.

• Registrazione, eventi, integrazione della logica aziendale: EF4 è come una scatola nera, fa qualcosa e tu non hai idea di cosa fa. C'è solo un evento OnSavingChanges in cui puoi inserire una logica di business che devi eseguire prima che accada qualcosa con DB, e se devi applicare alcune modifiche agli oggetti di business prima che accada qualcosa dovrai scavare in ObjectStateManager, e questo è davvero brutto , il codice può diventare enorme. Se ad esempio utilizzi il pattern Repository e cosa ricevere notifiche sulle modifiche apportate al DB in modo pulito, avrai difficoltà a farlo con EF.

• Estensibilità: tutto il codice EF è privato e interno, se non ti piace qualcosa (e non ti piacerà MOLTO se sei seriamente intenzionato a usare EF), in nessun modo lo cambierai in modo semplice, infatti sono sicuro è più facile scrivere il tuo ORM da zero (l'ho fatto) quindi far funzionare EF come ti serve. Ad esempio, dai un'occhiata al sorgente EFExtensions, si basa su metodi di estensioni e diversi "hack" per rendere EF un po 'più utilizzabile, e il codice è piuttosto brutto (e non è colpa degli autori, quando tutto in EF è privato questo è l'unico modo per estenderlo).

Posso continuare a scrivere cose cattive su EF e su quanto sia stato doloroso per me lavorarci per circa 20 pagine, e forse lo farò.

Che mi dici di NHibernate? È un livello assolutamente diverso, è come confrontare PHP con C #, EF4 è come nell'età della pietra, è come se EF fosse 10 anni indietro rispetto a NHibernate in fase di sviluppo, e in effetti lo è, Hibernate è stato avviato nel 2001. Se hai tempo libero per imparare e accendere Nhibernate, fallo.

Ecco il punto. NHibernate ed Entity Framework sono davvero per due diversi tipi di pubblico, nella mia mente. NHibernate sarebbe la mia scelta nella costruzione di un sistema con mappature, formule e vincoli complessi (praticamente qualsiasi cosa aziendale). Se volessi iniziare a correre con un semplice accesso ai dati, userei Entity Framework o LINQ-to-SQL. NHibernate non ha una chiara esperienza di "drag-and-drop" come EF. Entrambi hanno i loro punti di forza e di svantaggio. Il confronto tra mele e mele, francamente, non ti porta da nessuna parte.

Se pensi di voler eseguire il tuo codice su Mono, NHibernate è probabilmente una scelta migliore, indipendentemente da ciò che dicono le liste di controllo delle funzionalità ...

Modifica, 13/8/2012:

Entity Framework è stato open source ed è ora incluso in Mono a partire dalla versione 2.11.3. Questa risposta è ormai obsoleta e non dovrebbe essere invocata.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

La mia opinione su questo è che EF4.0 ha fatto molta strada dalla 1.0 e sta raggiungendo Nhibernate in termini di funzionalità, ma non è ancora tutto lì.

Tuttavia è Microsoft, fuori dagli schemi, e fa il 100% di ciò che il 95% delle applicazioni richiede. Tuttavia, NHibernate fa la stessa cosa da anni. La versione 5.0 o 6.0 potrebbe recuperare o addirittura superare NHibernate.

Ecco il mio consiglio: se hai tempo per imparare entrambe le cose, fallo. Ci sono diversi motivi per sceglierne uno piuttosto che l'altro. Se stai scrivendo codice per un'azienda, è realistico aspettarti di essere dipendenti capaci che abbiano familiarità con EF, come è in tutti i libri e in ciò che i bambini imparano al college. Se EF soddisferà le tue esigenze (pensa a questo lungo e duramente prima di dire semplicemente di sì), allora è una soluzione perfetta per ora, e in pochi anni potrebbe (ok, molto probabilmente lo farà) superare NHibernate.

NHibernate è un prodotto molto maturo con alcuni anni su EF e molto probabilmente farà tutto ciò che vorresti fare e anche alcuni. È stato il miglior ORM per un po 'di tempo e molte persone lo usano.

Penso che il fatto che EF 4 avrà la capacità di utilizzare POCO e il caricamento lento differito sarà molto grande. Potrei sicuramente vederlo guadagnare trazione con la nuova versione.

C'è un'ovvia tendenza all'aumento della popolarità di EF rispetto a NHibernate, guarda l'immagine.

I miei 2 centesimi: usiamo ef sul nostro client desktop per un po 'di cahing, ecc. - nessun carico. Un NHib sul lato server, che utilizza sessioni stateless, generazione di id hilo e batch. È abbastanza veloce nell'inserire 3k + messaggi in db al secondo. Inoltre è molto flessibile e supporta molti db, il che è fondamentale per il nostro prodotto.

La mappatura diretta alle stored procedure con una combinazione di Linq per un livello logico sembra l'approccio più semplice. Nessun xml. Genera sql solo per query interessanti che sono usate meno frequentemente o non adatte per stored procedure.

Gli oggetti vengono caricati e archiviati tramite SP standard. Questo approccio consente l'utilizzo di due accessi sql. Uno per l'accesso alla classe tramite SP (autorizzazioni di sola esecuzione) e uno per un modulo linq logico che consente l'accesso diretto alla tabella.

Scegliere tra gli ORM in base alla popolarità non è la cosa migliore da fare. Ho provato a trasferirmi a EF negli ultimi 2 anni e tutto quello che posso dire è, perché diavolo ci provo ancora?

ATM, il mio punto di vista sull'EF è: "È fatto per sistemi di bit davvero piccoli con non più di 3 tabelle con meno di 1 relazione (0 è meglio)".

E perché la penso così? 1. Prova ad aggiornare un grafico disconnesso e guarda il tuo modello graffiato;

1. Prova a creare TPH con alberi ereditati in profondità e scoprirai che sei schackato in una singola gerarchia o il sistema si romperà.

2. Prova a fare query più ingombranti e guarda l'intero sistema mangiare la pila: D ... gli overflow si verificano molto spesso.

3. Map XML datatypes si basa sulle estensioni o sulle proprietà NotMapped più "odiate" ... ed è anche peggio.

4. Prova a mescolare query SQL in Linq per query più fini e romperai il muro lol.

5. E l'ultima e più importante cosa, EF non supporta la formula della proprietà ("risorse fantastiche che NH ha per i database legacy") e non supporta i mapping di tipi complessi per la stessa tabella e le tabelle correlate.

Questa è la mia 10cc.