Entity Framework 4 vs NHibernate

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 rimuova NHibernate da questa posizione. Penso che se Microsoft ha davvero iniettato ottime funzionalità in EF4, può dare una buona competizione a NHibernate in quanto ha 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 pronta per lo sviluppo n-tier, in ” quadro auto-localizzanti”. Nessuno ha rilasciato codice comparabile per NHib.

NHib ha molte caratteristiche che non sono state menzionate come facenti parte di EF4. Questi includono l’integrazione della cache di secondo livello. Offre inoltre una maggiore flessibilità nella mapping dell’ereditarietà, una migliore integrazione con stored proc / funzioni di database / trigger SQL / trigger personalizzati, supporto per le proprietà della formula e così via. IMO è fondamentalmente solo più maturo come un ORM.

Aggiornamento: non ho usato Entity Framework dalla versione 4.0, quindi la mia risposta può essere superata. Sto ancora usando NH o puro ADO .NET nei miei progetti. E non voglio nemmeno vedere le novità in EF dal 4.0, perché l’NH funziona perfettamente.

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

Problemi EF4:

  • Eager Caricamento e definizione del risultato : il sistema di caricamento EF4 eager (Include (“Path”)) genera SQL non corretto, con JOIN di looping, che eseguirà migliaia (non letteralmente) il tempo più lento per le relazioni molti-a-molti, quindi SQL scritto a mano (è efficacemente inutilizzabile).
  • Materializer non può materializzare le entity framework associate : se pensi di poter superare il problema precedente fornendo la tua query SQL, ti sbagli. EF4 non può materializzare (mappare) le entity framework associate dalla query SQL JOIN, può solo caricare dati da una tabella (Quindi se hai Order.Product, SELECT * FROM order LEFT JOIN Il prodotto inizializzerà solo l’object Order, il Prodotto rimarrà nullo, pensato che tutti i dati necessari vengano recuperati nella query per iniziarlo). Questo può essere risolto usando il componente aggiuntivo della community di EFExtensions, ma il codice che dovrai scrivere per questo è davvero brutto (ho provato).
  • Entità di auto-localizzazione: molti dicono che le quadro di auto-tracciamento sono interessanti per lo sviluppo di livelli N, compresa la risposta più importante in questo thread. Ho pensato che non ho nemmeno provato, posso dire che non lo sono. Ogni input può essere falsificato, non puoi semplicemente prendere le modifiche che l’utente ti invia e applicarle alla base dati, perché non fornire all’utente i dati diretti accesso base allora? Qualsiasi modo per caricare i dati dell’utente è in procinto di cambiare da DB, controllare che esista | non esiste fare controlli sulle autorizzazioni ecc. Ecc. Non puoi fidarti dell’utente sullo stato di quadro che sta inviando al server, lo farai comunque devi caricare questa quadro dal DB e determinarne lo stato e altre cose, quindi questa informazione è inutile, così come le quadro di auto-monitoraggio a meno che tu non faccia un sistema privato di livello n fidato per uso interno, nel qual caso forse potresti dare semplicemente Accesso al database (Questa è la mia opinione su ST Entities e N-tire, non sono molto esperta in N-Tier, quindi può cambiare, se ho frainteso qualcosa qui commentarlo)

  • Registrazione, eventi, integrazione della logica di business: EF4 è come una scatola nera, fa qualcosa e non hai idea di cosa faccia. C’è un solo evento OnSavingChanges in cui è ansible inserire una logica di business che è necessario eseguire prima che qualcosa accada con DB, e se è necessario applicare alcune modifiche agli oggetti di business prima che qualcosa accada si dovrà scavare in ObjectStateManager, e questo è veramente brutto il codice può diventare enorme. Se, ad esempio, si utilizza il modello di repository e cosa notificare in caso di modifiche apportate a DB in modo pulito, sarà difficile farlo con EF.

  • Estensibilità: tutto il codice EF è privato e interno, se non ti piace qualcosa (e non ti piacerà un sacco se sei serio sull’uso di EF), in nessun modo cambierai questo in modo semplice, infatti sono sicuro è più facile scrivere da solo l’ORM (l’ho fatto), quindi rendere l’EF funzionante come è necessario. Ad esempio, date un’occhiata al sorgente EFExtensions, si basa su metodi di estensioni e diversi “hack” per rendere EF poco 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 negative su EF e quanto è stato doloroso per me lavorarci per 20 pagine simili, e forse lo farò.

Che ne pensi di NHibernate? È assolutamente diverso, è come paragonare PHP a C #, EF4 è come in Stone-age, è come EF è 10 anni dietro a NHibernate nel progresso dello sviluppo, e infatti è, Hibernate è stato avviato nel 2001. Se hai tempo libero per imparare e accendere Nhibernate, fallo.

Ecco la cosa. NHibernate ed Entity Framework sono in realtà per due diversi tipi di pubblico, nella mia mente. NHibernate sarebbe la mia scelta nella costruzione di un sistema con mappature complesse, formule e vincoli (fondamentalmente qualsiasi impresa). Se volessi un approccio pratico 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 gli svantaggi. Confrontandoli con le mele, le mele, francamente, non ti portano da nessuna parte.

Se pensi che potresti voler eseguire il tuo codice su Mono, NHibernate è probabilmente una scelta migliore a prescindere da ciò che dicono le checklist delle funzionalità …

Modifica, 13/08/2012:

Entity Framework è stato open source e ora è incluso in Mono dal 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 versione 1.0 e sta recuperando la funzionalità di Nhibernate, ma non è ancora tutto lì.

Tuttavia è Microsoft, out of the box, e fa il 100% di ciò che il 95% delle applicazioni ha bisogno di fare. Tuttavia, NHibernate ha fatto la stessa cosa per anni. La versione 5.0 o 6.0 potrebbe raggiungere o addirittura superare NHibernate.

Ecco il mio consiglio: se hai tempo per imparare entrambi, allora fallo. Ci sono diversi motivi per scegliere l’uno rispetto all’altro. Se stai scrivendo il codice per una società, è realistico aspettarsi di essere in grado dipendenti che abbiano familiarità con EF, come è in tutti i libri e ciò che i bambini imparano al college. Se EF soddisferà i tuoi requisiti (pensa a questo lungo e difficile prima di dire solo sì), allora è una soluzione perfetta per ora, e in alcuni anni potrebbe (ok, molto probabilmente) superare NHibernate.

NHibernate è un prodotto molto maturo con pochi anni di EF e molto probabilmente farà tutto ciò che vorresti fare e poi 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 usare POCO e il caricamento pigro posticipato sarà molto grande. Potrei sicuramente vederlo prendere quota con la nuova versione.

C’è una tendenza evidente dell’aumento della popolarità EF su NHibernate, vedi l’immagine.

NHibernate vs Entity Framework

I miei 2 centesimi: usiamo ef sul nostro client desktop per un po ‘di ecc. Un NHib sul lato server: utilizzo di sessioni Stateless, generazione di ID hilo e batch. È abbastanza veloce nell’inserire messaggi 3k + in db al secondo. Inoltre è molto flessibile e supporta molti dbs, che è fondamentale per il nostro prodotto.

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

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

Scegliere tra gli ORM per popolarità non è la cosa migliore da fare. Ho cercato di passare a EF negli ultimi 2 anni e tutto quello che posso dire è, perché diavolo ci provo ancora?

ATM il mio punto di vista su EF è: “E ‘fatto per sistemi veramente piccoli, piuttosto piccoli, con non più di 3 tabelle con meno di 1 relazione (0 è migliore)”.

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

  1. Prova a creare TPH con alberi ereditati in profondità e scoprirai di essere incatenato a una singola gerarchia o il sistema si romperà.

  2. Prova a fare domande più ingombranti e guarda l’intero sistema a mangiare fuori dalla pila: D … gli overflow accadono molto spesso.

  3. I tipi di dati XML della mappa si basano su estensioni o sulle proprietà NotMapped più “odiate” … ed è anche peggio.

  4. Prova a mescolare la query SQL in Linq per ulteriori query più dettagliate e rompi il muro lol.

  5. E l’ultima e più importante cosa, EF non supporta la formula di proprietà (‘una risorsa eccezionale che NH ha per i database legacy’), e non supporta i mapping di tipi complessi per la stessa tabella e le tabelle correlate.

Questo è il mio 10cc.