Entity framework vs NHibernate - Performance

Question

Sto cercando di implementare un ORM nel nostro sistema. Al momento abbiamo molte tabelle con molti dati orribili e stored procedure. Ho sentito che usare un ORM può rallentare il sistema. Qualcuno sa quale ORM è migliore in termini di velocità e prestazioni utilizzando le query create nel codice C# e la mappatura delle stored procedure?

Grazie

EDIT:

Il progetto userà le tabelle esistenti che sono grandi e contengono un sacco di dati, sarà anche utilizzare le stored procedure esistenti che svolgono compiti complessi in un DB SQL Server. L'ORM deve essere in grado di eseguire transazioni e avere prestazioni elevate durante l'esecuzione delle stored procedure esistenti e l'interrogazione delle tabelle correnti. Il progetto è basato sul web e utilizzerà i servizi web WCF con DDD. Posso vedere che EF è molto più facile da usare e ha un supporto maggiore, ma se NH è l'opzione più adatta?

Answer 1

Entity Framework implementa costantemente nuove funzionalità e tutto è automatizzato nel progetto. È molto facile utilizzare Entity Framework, estendere e ridefinire il codice. Visual Studio lo integra (Code-First, Database-first, Entity-First ...) come un fascino. Windows Azure facilita la distribuzione e la modifica. Inoltre Visual Studio può generare tutte le tue pagine CRUD in 3 click.

Ti suggerisco di utilizzare EF, ma dipende dal tuo progetto. Puoi darci maggiori dettagli a riguardo?

È possibile trovare molte tabelle di confronto su Google, ad esempio this one spiega le prestazioni e le differenze this one.

EDIT:

Potete quantificare il numero di utenti nella vostra applicazione?

Quando si utilizza Database-First in EntityFramework, è molto semplice per import and use stored procedures, per NHibernate esso quite simple pure. Si noti che se si utilizzano molte stored procedure e non molti utenti simultanei la scelta di un ORM tra questi due potrebbe non essere così cruciale.

Inoltre, non dimenticare che le prestazioni di uno strumento si basano spesso sul modo di utilizzarlo. Se usi male l'ORM (ad es. Async, caricamento pigro/bisognoso, classi base, ...) le prestazioni diminuiranno drasticamente.

Forse è possibile installarli entrambi, osservare come funzionano e controllare la loro tabella di marcia (ad esempio Entity framework) per verificare l'evoluzione e l'interesse.

Answer 2

Entrambe sono ottime soluzioni, anche se personalmente penso che NHibernate sia migliore per un database ereditato. Qui è una buona caratteristica-saggio confronto -

http://www.dennisdoomen.net/2013/03/entity-framework-56-vs-nhibernate-3.html

Ci sono alcune cose che sono chiaramente meglio in NHibernate, come il supporto di memorizzazione nella cache di secondo livello. La documentazione è probabilmente un po 'più rada di EF, ma se sei disposto a passare attraverso la curva di apprendimento, NHibernate ti dà molta più energia.

FluentNHibernate è ideale per la mappatura digitata delle classi alle tabelle sottostanti, ma ci sono alcuni punti in cui è necessario ripristinare i mapping XML. C'è comunque una nuova API concorrente da NHibernate stessa, e non l'ho ancora verificata (il blog post sopra lo menziona).

Se si desidera fare affidamento sul supporto degli utensili VS, EF è migliore. Tuttavia a volte ci sarà qualche magia (per esempio EF può usare la riflessione per popolare anche le proprietà private di un oggetto, NHibernate non lo fa, questo è un punto di forza o di debolezza a seconda di come lo vedi). EF funziona anche bene con altri framework forniti da Microsoft (ad esempio, servizi RIA). Mi piacciono anche le migrazioni EF-auto (quando usi il codice prima).

Se si desidera più potenza nelle proprie mani e si vuole essere in grado di mettere a punto come funzionano le cose con una chiara separazione delle preoccupazioni (ORM fa solo quello che dovrebbe fare l'ORM), NH sembra essere migliore. Tuttavia, è un po 'irritante rendere tutte le proprietà virtuali per NH essere in grado di accedervi.

Ho usato entrambi e può diventare un po 'goffo in entrambi i modi per generare lo sql desiderato; in quei casi del 5-10%, scendi di un altro livello e usa un micro-ormo come Dapper, Massive o Petapoco.

EDIT: troppo

NHibernate possibile popolare proprietà private, apparentemente, quindi questo era solo l'ignoranza da parte mia.

Answer 3

EF 5 o 6 su .NET 4.5 è un modo sicuro per aumentare le prestazioni, non aspettatevi alcun miglioramento della velocità con EF 5 su .NET 4.0, questo è documentato da Microsoft. (Abbiamo anche un altro problema con le dichiarazioni LINQ scritte male).

In generale, se le prestazioni sono prioritarie, non è possibile battere ADO.NET con stored procedure. Semplicemente non puoi. Aggiunto ORM, aggiunta e contenitore IOC ... quanti test per le prestazioni vuoi fare?

Girare un po 'di macchine virtuali con JMETER e colpire un server con EF e ne ha colpito un altro con NHibernate. Basta forzare JMETER a effettuare chiamate sufficienti a URLS e verificare la quantità di utenti simultanei e dovresti vedere dove si trova il collo di bottiglia.

Answer 4

Può valere la pena aggiungere qui Entity Framework ha problemi quando si collegano i grafici disconnessi e manca funzionalità come l'unione in Nhibernate. Puoi indirizzarlo con altri plugin, ma non fuori dalla scatola. Ecco un link per la funzionalità su Codeplex che richiede un supporto migliore per lavorare con entità disconnesse, e c'è qualche ulteriore discussione.

Answer 5

check this artical alcuni vantaggi di NH oltre EF

1. NH vanta oltre 10 strategie generatore id (identità, sequenza, Hilo, manuali, incremento, diversi GUID, ecc), EF ha solo IDENTITÀ manuale o SQL Server di ;
2. NH ha il supporto di proprietà lazy (nota: non entità, questo è per le proprietà string, XML, ecc), EF no;
3. NH dispone di supporto cache di secondo livello (e, credetemi, gli sviluppatori aziendali lo stanno utilizzando) e EF no;
4. NH ha il supporto per i tipi personalizzati, anche complessi, con proprietà "virtuali", che include l'interrogazione per queste proprietà virtuali, EF no;
5. NH ha proprietà formula, che possono essere qualsiasi SQL, EF no;
6. NH ha filtri automatici per entità e collezioni, EF no;
7. NH supporta raccolte di tipi primitivi (stringhe, interi, ecc.) Nonché componenti (tipi complessi senza identità), EF no;
8. NH supporta 6 tipi di raccolte (elenco, set, borsa, mappa, array, matrice di ID), EF ne supporta solo uno;
9. NH include un generatore di proxy che può essere utilizzato per personalizzare i proxy generati, EF non lo consente;
10. NH dispone di 3 opzioni di mappatura (.HBM.XML, per codice, per attributi) e EF solo due (per attributi, per codice);
11. NH consente il batch di query e inserimento (questo perché EF supporta solo i tasti IDENTITY), EF no;
12. NH ha diverse strategie di controllo ottimista (colonna sul db, tra cui ORA_ROWSCN, timestamp, la versione intera di Oracle, tutti, colonne sporchi), EF supporta solo timestamp di SQL Server' o tutti