NHibernate vs. Entity Framework
This post was originally published on Coding Glamour.
We gebruiken sinds de laatste rewrite van onze codebase (2006) NHibernate
als OR Mapper, maar na ruim vier jaar is nu het besef wel gekomen dat we
eens zouden moeten upgraden, daar we nu nog op NHibernate 1.04 draaien
(2.1.2 is nu uit, en 3.0 is in beta). Daarom gisteren een kennissessie
[1] gehad waarin we eens bespraken welke richting we uit wilden. Bij NHibernate
blijven of toch naar Entity Framework.
[1] Gooi een sloot developers met eten en alcohol in een groen hok en wacht tot ze het eens zijn.
Huidige landschap
Grootste nadeel van NHibernate op dit moment in onze situatie:
- Zeer onduidelijke foutmeldingen
- Runtime compilation van entities kost enorm veel tijd (30 sec. per compilatieslag)
In NHibernate 2.1.2 is op dit moment geen fatsoenlijke strong-typed LINQ support, en er zijn bovendien dezelfde bezwaren die ons nu soms ook opbreken als een gebrek aan goede documentatie, goede foutmeldingen en static compilation.
Dan naar NHibernate 3.0?
Het belooft in ieder geval een meer feature-rijke release te worden. Normale LINQ support, alhoewel er geen binding is tussen de DataContext waarin je draait en je entity (je kunt met LINQ een query uitvoeren op een type dat niet bestaat in de database waarop je queriet, dit merk je pas runtime); en in bèta 1 zijn de foutmeldingen nog niet verbeterd. Alhoewel hier beterschap voor is beloofd.
Daarnaast is het voor mij eigenlijk onbegrijpelijk dat door het loskoppelen van het proxy-framework van de NHibernate core, álle classes die lazy-loading willen ondersteunen, alle properties als 'virtual' gedefinieerd moeten hebben. Daarnaast zal er ook geen static compilation komen, waardoor we nog steeds lang moeten wachten totdat NHibernate alles runtime heeft gecompileerd.
Overigens zijn er inmiddels extension-points in NHibernate waardoor je dit zou kunnen cachen, en deze slag zo'n 50% sneller kan laten verlopen.
Waarom wél NHibernate?
Alles, van voor naar achter, van links naar rechts, van API tot aan Business Rules, alles draait NHibernate. Alle core components, mappers, etc. kunnen allemaal met HQL werken. Dat betekent een minimale impact op de code, maar wel een sloot aan nieuwe features. Daarnaast is NHibernate qua ORM zelf de beste (?) mapper at the moment. Wij gebruiken in ieder geval in een aantal entities methodes die niet ondersteund worden in EF (moeilijke complex types uit een rij mappen).
Waarom Entity Framework?
We kunnen nu model-first werken, waarin we alle entities die nu met NHibernate praten; gewoon kunnen laten bestaan, maar ze én tegen NHibernate én tegen Entity Framework te laten mappen. Dat scheelt werk.
Daarnaast is er een fantastische Visual Designer, die goed geïntegreerd is in Visual Studio; en is EF4 een requirement voor het behalen van je MCPD (Microsoft Professional Developer) .NET 4, dus meer kennis aanwezig bij externe ontwikkelaars.
Documentatie en static compilation zijn daarnaast twee zaken die veel tijd kunnen gaan schelen bij het ontwikkelen, namelijk sneller foutmeldingen zien, en sneller doorwerken na een compilatieslag.
Ook prettig is dat er een sterke partij achter staat, want wanneer Ayende (lead dev van NHibernate) onder een bus zou komen, zou dat NHibernate ernstig schaden.
Waarom géén Entity Framework?
De omzetting van NH naar EF gaat een best gevaarlijke stap worden, omdat alle code die communiceert met een database herschreven moet worden. Fouten worden snel gemaakt, en hoeven niet altijd direct op te vallen in een codebase van 2.000.000 regels code. Daarnaast is het minder 'proven technology' dan Hibernate, dat veel langer op de markt is.
Ook heeft Entity Framework wat rare quirks die ook in NHibernate voorkomen, zoals het zomaar weggooien van data als je Primary Key's niet uniek zijn gedefinieerd. Tevens gemerkt bij een eerdere werkgever dat EF inline queries nogal in de hand werkt; omdat je valide C# aan het typen bent, en geen obscure taal als HQL, dus er moet goed nagedacht worden hoe we de DataContext'es gaan afschermen.
Long story short
We hebben nog geen flauw idee wat we gaan doen .
There are 14 comments on this article, read them on Coding Glamour.