Hintergrund
In den frühen Tagen von .NET war das System.Data-Framework ein wichtiger Bestandteil. Es bietet eine Möglichkeit, .NET-Datenbanktreiber zu erstellen, ähnlich den ActiveX-Datenobjekten von Visual Basic. Obwohl die API anders ist, wird ihr Name wiederverwendet, daher der Spitzname ADO .NET.
Ein wesentlicher Unterschied zwischen ADO und ADO .NET (also System.Data) ist das Objektmodell. In ADO muss man normalerweise nur Connection-, Command- und Recordset-Objekte verwenden, und der OleDB/ODBC-Treiber verbirgt etwas anderes. Dies verbessert die Wiederverwendung von Code, aber es ist für Entwickler schwierig, einige Datenbankfunktionen bereitzustellen.
In ADO .NET kannst du auch OleDB/ODBC verwenden, aber in den meisten Fällen wirst du eine Reihe datenbankspezifischer Klassen verwenden. Diese Klassen stammen aus DBConnection, DBCommand, und DBDataReader, die die Wiederverwendbarkeit des Originalcodes erhalten. Da es sich jedoch um stark benannte Typen handelt, müssen sie explizit Teil der .NET-Bibliothek sein.
Wahrscheinlich um die Entwicklung zu vereinfachen, sind SQL Server, OleDB und ODBC-Treiber alle Teil des System.Data-Frameworks. Dieser Ansatz war damals akzeptabel, verursachte jedoch Probleme im aktuellen Entwicklungszyklus von SQL Server.
Tatsächlich haben sich die Releasezyklen von SQL Server von 3 bis 5 Jahren auf fast jedes Jahr geändert. Neue Versionen erfordern häufig Updates des .NET-Treibers, was nicht möglich ist, wenn er an den .NET-Standard-Release-Zyklus gebunden ist.
Der erste Schritt ist die Aufteilung der System.Data-Bibliothek. NET Core erreicht diesen Schritt, indem es für jeden Datenbanktreiber separate Bibliotheken bereitstellt. Der nächste Schritt ist, den SQL-Server-Treiber vollständig von .NET Core/Standard zu trennen. Dafür haben sie Microsoft.Data.SqlClient erstellt.
Upgrade auf Microsoft.Data.SqlClient
Für die meisten Entwickler ist die Nutzung von Microsoft.Data.SqlClient sehr einfach, indem man einfach die Using-Anweisung am oberen Rand jeder Klasse modifiziert. Außerdem verwendet es dieselben Klassennamen und APIs und bietet ungefähr die gleichen Funktionen.
Für leichte ORMs wie Dapper oder RepoDB sind keine weiteren Änderungen erforderlich.
Wenn Entwickler ORMs zur Verwaltung von Verbindungen verwenden (z. B. EF, NHibernate), müssen sie auf ORM-Upgrades warten.
Die problematischeren sind die, die ORMs mischen. Wenn ein ORM Microsoft.Data.SqlClient und das andere System.Data.SqlClient verwendet, funktioniert es nicht gleichzeitig. Dies ist besonders wichtig bei der Arbeit mit gemeinsamen SqlTransaction-Objekten.
Brauchbarkeit
Version 1.0 von Microsoft.Data.SqlClient ist für diese Plattformen verfügbar:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Bekannte Probleme
Nicht jeder muss sofort aufrüsten. Diese bekannten Probleme sind in der Dokumentation vermerkt:
- User Data Type (UDT) funktioniert möglicherweise nicht mit Microsoft.Data.SqlClient.
- Azure Key Vault und Microsoft.Data.SqlClient haben keinen Keystore.
- Microsoft.Data.SqlClient unterstützt Always Encrypted für sichere Enklaven nicht.
- Nur .NET Framework und .NET Core unterstützen Always Encrypted, .NET Standard nicht, da .NET Standard einige Verschlüsselungsabhängigkeiten fehlen.
Originallink:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Veröffentlicht am 27.12.2021 22:21:14
|
|
|
