Ein kurzer Blick auf die Entstehungsgeschichte von EF Core und NHibernate erklärt, warum sich beide Frameworks konzeptionell unterscheiden: NHibernate entstand 2003 als Portierung des Java-Frameworks Hibernate auf .NET und wird seit 2006 vollständig als Open-Source-Projekt weiterentwickelt. Das Framework ist komplett in C# implementiert und verfügt über eine aktive Community mit verschiedenen Unter- und Zusatzprojekten. Die aktuelle Hauptlinie (z. B. Version 5.5.x) unterstützt:

• .NET 6 und höher
• .NET-Standard 2.0
• .NET Framework 4.6.1 und höher

NHibernate wird als NuGet-Paket ausgeliefert und steht unter der Lizenz LGPL-2.1-only; kann also überall, auch kommerziell, genutzt und distribuiert werden, solange das Paket unverändert bleibt.

Entity Framework wurde 2008 als Bestandteil des .NET-Frameworks 3.5 SP1 eingeführt. Die erste Generation von Entity Framework war eng mit dem klassischen .NET Framework und Microsofts SQL Server verknüpft. Ab 2016 folgte dann eine komplette Neuentwicklung als EF Core, seitdem:

• quelloffen
• modular über NuGet-Pakete
• unter MIT-Lizenz
• mit Unterstützung für zahlreiche relationale Datenbanken

Seit EF Core 6 gilt PostgreSQL als primäre Entwicklungsplattform im Microsoft-Team. Beide Projekte sind also etabliert, aktiv gepflegt und offen lizenziert. Der Unterschied liegt weniger in der „Modernität“ als in Architektur und Philosophie.

Architektur: Session vs. DbContext

Beide Frameworks abstrahieren den Zugriff auf relationale Datenbanken, setzen aber unterschiedliche Schwerpunkte in ihrer Architektur.

NHibernate: Session- und Factory-Konzept

NHibernate verwendet ein zweistufiges Modell:

• Die ISessionFactory wird in der Regel einmal pro Anwendung oder Kontext erstellt. Sie ist vergleichsweise aufwendig zu initialisieren, hält dafür sämtliche Mapping-Informationen, Konfiguration und Cachestrategien.
• Die ISession repräsentiert eine kurzlebige Arbeitseinheit (z. B. einen Web-Request oder eine fachliche Unit-of-Work). Sie übernimmt:
  • Verwaltung von Objektinstanzen
  • Change-Tracking innerhalb der Session
  • Steuerung von Transaktionen (via ITransaction)
  • Zugriff auf die Datenbank über den konfigurierten ADO.NET-Provider

Dieses Modell fügt sich sehr gut in klassische Patterns wie Repository und Unit-of-Work ein. Domänenklassen müssen NHibernate nicht kennen und bleiben als reine POCOs nutzbar.

EF Core: DbContext als zentrale Instanz

EF Core bündelt mehrere Verantwortlichkeiten im DbContext:

• Konfiguration (via OnConfiguring/OnModelCreating)
• Change-Tracking über den ChangeTracker
• Zugriff auf Entitätstypen über DbSet<T>
• Verbindungs- und Transaktionsverwaltung

In Webanwendungen wird der DbContext typischerweise per Dependency Injection pro Scope (z. B. pro Web-Request) bereitgestellt, auch in Desktopapplikationen setzen sich DI-Konzepte immer mehr durch. Das erleichtert den Einstieg und die Integration in gängige .NET-Anwendungen, führt aber auch zu einer stärkeren technischen Bindung des Anwendungscodes an EF Core.

Konfiguration und Mapping

Ein zentrales Thema jedes O/R-Mappers ist die Frage, wie Klassen und Datenbankobjekte einander zugeordnet werden.

NHibernate: POCOs und flexible Mapping-Ansätze

NHibernate arbeitet mit POCO-Klassen:

• Die gemappten Eigenschaften werden in der Praxis oft als virtual deklariert, damit NHibernate Proxies für Lazy Loading und Change-Tracking erzeugen kann.
• Nicht gemappte Eigenschaften erfordern keine explizite Konfiguration.

Für das Mapping stehen mehrere Ansätze zur Verfügung:

• HBM/XML: Klassisches Mapping über XML-Dateien, vollständig getrennt von den Domänenklassen.
• Mapping-by-Code / Fluent API: Konfiguration in C# über ein Fluent API.

Die parallele Existenz von XML- und Fluent-Mapping kann in der Einarbeitung anspruchsvoll sein, bietet im Gegenzug jedoch eine hohe Flexibilität, insbesondere, wenn Domänenmodell und Persistenzkonfiguration bewusst getrennt gehalten werden sollen.

EF Core: Konventionen, Fluent API und DataAnnotations

EF Core setzt stärker auf ein Konventionsmodell:

• Bestimmte Namenskonventionen (z. B. Id oder <Typname>Id) werden automatisch als Primärschlüssel interpretiert, weitere Namenskonventionen sorgen für eine durchgängige Gestaltung des Modells.
• Navigationseigenschaften werden als Relationen erkannt.

Ergänzend stehen folgende Mechanismen zur Verfügung:

• Fluent API in OnModelCreating des DbContext
• DataAnnotations direkt an den Entitätsklassen

Die Konventionen lassen sich also überschreiben, wenn gewünscht. Nicht gemappte Eigenschaften müssen in EF Core in der Regel explizit ausgeschlossen oder konfiguriert werden. Entitäten bleiben formal POCOs, sind aber durch DataAnnotations und EF-spezifische Konzepte oft eng mit dem EF-Core-Modell verzahnt.

Code First, Database First und Reverse Engineering

Sowohl NHibernate als auch EF Core unterstützen Code-First- und datenbankzentrierte Ansätze, allerdings mit unterschiedlichen Komfortniveaus.

NHibernate

• Code First:
  • NHibernate bietet mit SchemaExport und SchemaUpdate Werkzeuge zur Erzeugung und Aktualisierung von Datenbankschemas aus dem Mapping.
  • Darüber hinaus existieren Drittanbietertools, die POCOs oder Mapping-Dateien generieren können.
• Reverse Engineering (Database First):
  • In der Basis werden Datenbankmodelle eher manuell oder über externe Werkzeuge in Mappings überführt.
  • Tools wie der DevArt Entity Developer können sowohl NHibernate- als auch EF-Core-Modelle aus bestehenden Datenbanken erzeugen.

NHibernate stellt damit die erforderlichen Bausteine bereit, überlässt die Gestaltung eines umfassenden Migrations- und Modellierungsprozesses aber stärker den Projekten selbst bzw. Drittwerkzeugen.

EF Core

EF Core ist explizit für Code First entworfen:

• Modelländerungen werden über Migrationen nachvollziehbar gemacht.
• Über CLI- oder PowerShell-Befehle (z. B. dotnet ef migrations add, dotnet ef database update) lässt sich das Datenbankschema schrittweise anpassen.
• Die dafür benötigten Funktionen werden durch Microsoft.EntityFrameworkCore.Tools bereitgestellt.
• Die Database-Property des DbContext stellt Methoden wie EnsureCreated(), Migrate() etc. bereit, um Migrationen per Code ausführen zu lassen.

Für Reverse Engineering existiert mit Scaffold-DbContext (ebenfalls in Microsoft.EntityFrameworkCore.Tools) ein integriertes Werkzeug, das aus einem bestehenden Schema Entitätsklassen und einen passenden DbContext generiert.

Damit bietet EF Core im Standard deutlich mehr Out-of-the-box-Unterstützung für einen durchgängigen Code-First-Entwicklungsprozess.

Ladestrategien und Performance

Das Ladeverhalten von Objektgraphen hat großen Einfluss auf Performance und Ressourcenauslastung.

NHibernate: Konfigurierbare Fetch-Strategien

NHibernate bietet verschiedene Mechanismen zur Steuerung des Ladeverhaltens:

• Lazy Loading über Proxies: Mit session.Load<T>(id) werden zunächst Proxy-Objekte erzeugt, die beim ersten Zugriff aufgelöst werden.
• Explizites Laden: session.Get<T>(id) lädt eine Entität unmittelbar aus der Datenbank.
• Fetch-Strategien im Mapping: Über das Mapping (XML oder Fluent) kann festgelegt werden, ob Relationen standardmäßig lazy, eager oder z. B. per subselect geladen werden.
• Batch-Fetching: Mehrere abhängige Entitäten können in Batches geladen werden, um N+1-Selektionsprobleme zu vermeiden.

Neben LINQ stehen Entwickelnden noch weitere, teils historisch anmutende Abfragesprachen (Hibernate Query Language (HQL), Criteria, QueryOver) zur Verfügung; die Session stellt jedoch mit CreateSQLQuery() auch eine Methode für direktes SQL bereit.

Diese Möglichkeiten erlauben eine sehr feingranulare Abstimmung des Ladeverhaltens – bei Bedarf auch global über das Mapping.

EF Core: Include und optionale Proxies

In EF Core steht die Abfrage stärker im Mittelpunkt der Steuerung:

• Standardmäßig wird über LINQ gearbeitet, direktes SQL ist in Version 10 immer noch möglich, wenn auch nicht wirklich komfortabel.
• Mit .Include() und .ThenInclude() lässt sich festlegen, welche Navigationspfade im Rahmen einer Abfrage eager geladen werden sollen.
• Optional kann über das NuGet-Paket Microsoft.EntityFrameworkCore.Proxies Lazy Loading per Proxy aktiviert werden.

EF Core setzt damit vor allem auf eine explizite, abfragebezogene Steuerung. Das ist gut nachvollziehbar, erfordert aber Disziplin in der Formulierung komplexerer Abfragen.

Change Tracking und Persistenz

Beide Frameworks verfolgen Änderungen an Entitäten und schreiben diese in die Datenbank, unterscheiden sich aber in der Ausgestaltung.

NHibernate: Session-gesteuertes Change Tracking

In NHibernate verfolgt die ISession die Änderungen an verwalteten Entitäten. Typische Methoden sind:

• .Save(entity)
• .Update(entity)
• .Delete(entity)
• .Evict(entity) (Entfernen aus der Session)
• .Flush() (explizites Schreiben der Änderungen in die Datenbank)

Ein Transaction.Commit() löst in der Regel ebenfalls einen Flush der Session aus. Durch die expliziten Methoden lässt sich das Verhalten sehr gezielt steuern, z. B. für Batchverarbeitung oder klar definierte Units-of-Work.

EF Core: ChangeTracker und SaveChanges

EF Core bündelt das Change-Tracking im DbContext über den ChangeTracker:

• Entitäten, die über ein DbSet<T> geladen oder dem Kontext hinzugefügt werden, werden automatisch nachverfolgt.
• Änderungen werden durch Aufruf von DbContext.SaveChanges() (oder der asynchronen Variante) in die Datenbank geschrieben.

Dieses Modell ist sehr leicht verständlich und produktiv. Im Gegenzug ist die Lebensdauer des DbContext entscheidend, um unnötig große Tracking-Graphen zu vermeiden.

Primärschlüssel und Wertgenerierung

Die Art der Schlüsselgenerierung kann Einfluss auf Skalierbarkeit und Datenbankbelastung haben.

NHibernate

NHibernate unterstützt eine breite Palette an Strategien zur Primärschlüsselgenerierung:

• IDENTITY/Autoinkrement
• Sequenzen
• HI/LO-Algorithmen (eigene und datenbankspezifisch)
• GUID
• Datum/Uhrzeit
• manuelle Vergabe

Insbesondere die HI/LO-Algorithmen erlauben es, Datenbankzugriffe für die ID-Vergabe zu reduzieren, indem Blöcke von IDs im Voraus reserviert und lokal vergeben werden.

EF Core

EF Core bietet ebenfalls mehrere Strategien:

• IDENTITY/Autoinkrement
• Sequenzen
• manuelle Vergabe
• seit neueren Versionen: GUID und Datum/Uhrzeit als Schlüsseltypen

Für viele Standardfälle sind die bereitgestellten Mechanismen ausreichend. NHibernate bietet zusätzlich spezialisierte Strategien wie HI/LO, die in bestimmten Szenarien Vorteile bringen können.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Events und Interceptors

Erweiterungspunkte sind wichtig, um wiederkehrende Querschnittsanforderungen wie Auditing oder Multi-Tenancy konsistent umzusetzen.

NHibernate

NHibernate stellt eine Vielzahl von Events bereit, die nahezu alle relevanten Operationen einer Session abdecken:

• Pre-/Post-Insert
• Pre-/Post-Update
• Pre-/Post-Delete
• Load, Flush und Evict Events

Ergänzend können Interceptors eingesetzt werden, um Objekte vor Datenbankoperationen zu inspizieren oder zu modifizieren. Beispiele:

• automatisches Setzen von Auditfeldern (CreatedAt, ModifiedBy)
• Umsetzung von Soft Deletes
• Multi-Tenancy-Filterung

EF Core

Auch EF Core bietet Erweiterungspunkte:

• Events im DbContext und ChangeTracker (z. B. SavingChanges)
• Interceptors zur Beeinflussung von Datenoperationen und Datenbankkommandos (z. B. SaveChangesInterceptor)

Damit lassen sich viele typische Anforderungen umsetzen, wenn auch mit einem etwas anderen Zuschnitt als in NHibernate.

Entscheidungskriterien für die Praxis

Aus dem bisherigen Vergleich lassen sich einige typische Einsatzszenarien ableiten.

NHibernate

Szenarien, in denen NHibernate besonders interessant ist:

• Komplexe, langlaufende Geschäftsanwendungen mit Fokus auf klar getrennte Domänenschichten und DDD-Ansätze
• Projekte mit hohen Anforderungen an Performance und feingranulare Ladestrategien, etwa bei großen Objektgraphen oder hohen Zugriffszahlen
• Systeme mit anspruchsvollen Primärschlüsselstrategien (z. B. HI/LO) oder heterogenen Datenbanken
• Anwendungen mit ausgeprägten Querschnittsanliegen wie Auditing, Soft Deletes oder Multi-Tenancy, die über Events und Interceptors zentral umgesetzt werden sollen

EF Core

Szenarien, in denen EF Core naheliegt:

• Greenfield-Projekte, bei denen ein durchgängiger Code-First-Prozess mit integrierten Migrationen gewünscht ist
• Standardwebanwendungen mit typischen CRUD-Workloads, in denen EF-Core-Tooling und -Integration (ASP.NET Core, Identity etc.) im Vordergrund stehen
• Teams mit starkem Fokus auf LINQ und .NET-Standard-Stack, für die eine enge Integration in das Microsoft-Ökosystem Vorteile bietet.
• Projekte mit hohem Bedarf an Toolunterstützung und schneller Einarbeitung, z. B. in gemischten oder wechselnden Teams.

Fazit

NHibernate und EF Core sind beide leistungsfähige O/R-Mapper für .NET, die sich in ihrer Ausrichtung unterscheiden:

• NHibernate punktet mit einer klaren Trennung zwischen Domänenmodell und Persistenz, flexiblen Mapping-Optionen, umfangreichen Fetch-Strategien, vielfältigen Strategien zur Schlüsselgenerierung sowie einem breiten Angebot an Events und Interceptors. Es eignet sich besonders für komplexe, langfristig ausgelegte Geschäftsanwendungen, in denen eine fein abgestimmte Persistenzschicht gewünscht ist.
• EF Core überzeugt durch seine enge Integration in den .NET-Standard-Stack, exzellentes Tooling für Code First und Migrationen, gute LINQ-Unterstützung und eine im Alltag sehr produktive Arbeitsweise. Für viele typische Anwendungsfälle ist EF Core daher die naheliegende Wahl.

Statt NHibernate und EF Core als Konkurrenten im Sinne eines Entweder-oder zu betrachten, lohnt es sich, beide als Werkzeuge mit unterschiedlichen Stärken zu verstehen. In Projekten mit besonderen Anforderungen an Architektur, Kapselung und Performance kann NHibernate auch heute noch eine sehr interessante Alternative zu EF Core sein – und in bestimmten Szenarien klare Vorteile bieten.