Umstieg auf .NET Core, Teil 5: Datenzugriff auf .NET Core umstellen

Die Umstellung des Datenzugriffs auf .NET Core ist eine vergleichsweise leichte Disziplin – aber nur, wenn man auf zeitgemäße APIs verzichten kann.

Lesezeit: 10 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 34 Beiträge

(Bild: FreshPaint/Shutterstock.com)

Von
Inhaltsverzeichnis

Zum Zugriff auf Datenbanken bietet das klassische .NET Framework verschiedene Techniken:

  • ADO.NET-DataReader- und Command-Objekte
  • ADO.NET DataSets (im Standard untypisiert)
  • Typisierte DataSets auf Basis eines Code-Generators
  • Als objektrelationalen Mapper (ORM) das ADO.NET Entity Framework mit drei verschiedenen Vorgehensmodellen: Database First, Model First und Code First
  • Schließlich gibt es noch ORM-Produkte von kommerziellen Anbietern, beispielsweise XPO von DevExpress, LLBLGen Pro von Solutions Design bv sowie aus dem Open-Source-Bereich Dapper von StackExchange, PetaPOCO und nHibernate. Andere Produkte wie Telerik Data Access (früher "Open Access") sind angesichts der marktbeherrschenden Stellung von Entity Framework mittlerweile verschwunden.

DataReader- und Command-Objekte gibt es bereits seit .NET Core 1.0 (aus dem Jahr 2016). Das DataSet sollte es in .NET Core eigentlich nicht mehr geben: "We generally consider DataSet and friends (DataTable, DataView, TableAdapter) legacy." In .NET Core 2.0 hat Microsoft das DataSet mit seinen Unterklassen dann dennoch eingeführt. Der Codegenerator für typisierte DataSets sollte eigentlich schon in .NET-Core-3.0-Projekten funktionieren, ein gravierender Bug verhinderte das aber. In .NET-Core-3.1-Projekten ist die Codegenerierung für DataSets allerdings möglich.

Den verwendeten ADO.NET-Datenbankprovider braucht man in einer speziellen .NET-Core-Fassung. Microsoft selbst liefert .NET-Core-Treiber für SQL Server und SQL Server Compact sowie SQLite. Für den SQL Server gibt es seit August 2019 das Paket Microsoft.Data.SqlClient. Die aus dem klassischen .NET Framework bekannte Treiber-Bibliothek System.Data.SqlClient ist für .NET Core noch vorhanden, jedoch nur als Auslaufmodell. Neue Funktionen erscheinen nur noch mit Microsoft.Data.SqlClient.

Umstieg auf .NET Core

In dieser fünfteiligen Artikelserie geht Holger Schwichtenberg der grundsätzlichen Frage nach, ob Organisationen, die zum Teil schon seit Anfang der 2000er Jahre mit dem klassischen .NET Framework entwickeln, ihren bestehenden Programmcode nun auf .NET Core umstellen sollten. Ist die Entscheidung für eine Migration gefallen, dann gilt es, eine Reihe von Herausforderungen zu meistern:

Bei der Migration mit DataReader, Command und DataSet auf .NET Core bleibt eine Nickeligkeit: Während klassische .NET-Framework-Anwendungen beim Programmstart die Windows-Registrierungsdatenbank nach installierten Datenbankprovidern durchsuchen, ist dieses Verhalten in .NET Core – auch unter Windows – nicht mehr vorgesehen. Datenbankprovider, die man via ADO.NET verwenden will, sind daher bei Programmstart im Code zu registrieren:

System.Data.Common.DbProviderFactories.RegisterFactory("System.Data.SqlClient", System.Data.SqlClient.SqlClientFactory.Instance);

Im Bereich der Drittanbieter- und Open-Source-ORMs unterstützen sowohl alle oben genannten als auch andere Produkte inzwischen .NET Core – zum Teil aber mit funktionalen Einschränkungen (vgl. "Features not supported in the .NET Standard build").