bakgrund
I .NET:s tidiga dagar var System.Data-ramverket en viktig komponent. Det ger ett sätt att skapa .NET-databasdrivrutiner, liknande Visual Basics ActiveX Data Objects. Även om API:et är annorlunda återanvänds dess namn, därav smeknamnet ADO .NET.
En viktig skillnad mellan ADO och ADO .NET (dvs. System.Data) är objektmodellen. I ADO behöver du vanligtvis bara använda Connection-, Command- och Recordset-objekten, och OleDB/ODBC-drivrutinen döljer något annat. Detta förbättrar återanvändningen av kod, men det är svårt för utvecklare att exponera vissa databasfunktioner.
I ADO .NET kan du också använda OleDB/ODBC, men i de flesta fall använder du en serie databasspecifika klasser. Dessa klasser härstammar från DBConnection, DBCommand, och DBDataReader, som upprätthåller återanvändbarheten av originalkoden. Men eftersom de är starkt namngivna typer måste de explicit vara en del av .NET-biblioteket.
Troligen för att förenkla utvecklingen är SQL Server, OleDB och ODBC-drivrutiner alla en del av System.Data-ramverket. Denna metod var acceptabel vid den tiden, men skapade problem med den nuvarande utvecklingscykeln av SQL Server.
Faktum är att SQL Server-releasecykler har ändrats från 3 till 5 år till nästan varje år. Nya versioner kräver ofta uppdateringar av .NET-drivrutinen, vilket inte är möjligt om den är kopplad till .NET:s standardutgivningscykel.
Det första steget är att dela upp System.Data-biblioteket. NET Core utför detta steg genom att tillhandahålla separata bibliotek för varje databasdrivrutin. Nästa steg är att helt separera SQL Server-drivrutinen från .NET Core/Standard. För att göra detta skapade de Microsoft.Data.SqlClient.
Uppgradera till Microsoft.Data.SqlClient
För de flesta utvecklare är det väldigt enkelt att använda Microsoft.Data.SqlClient, bara att ändra using statement högst upp i varje klass. Dessutom använder det samma klassnamn och API:er, och erbjuder ungefär samma funktioner.
För lättviktiga ORM:er som Dapper eller RepoDB krävs inga ytterligare ändringar.
Om utvecklare använder ORM:er för att hantera anslutningar (t.ex. EF, NHibernate) måste de vänta på ORM-uppgraderingar.
De mer besvärliga är de som blandar ORM:er. Om en ORM använder Microsoft.Data.SqlClient och den andra använder System.Data.SqlClient, fungerar det inte samtidigt. Detta är särskilt viktigt när man arbetar med delade SqlTransaction-objekt.
användbarhet
Version 1.0 av Microsoft.Data.SqlClient finns tillgänglig för dessa plattformar:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Kända problem
Alla behöver inte uppgradera direkt. Dessa kända problem anges i dokumentationen:
- User Data Type (UDT) kanske inte fungerar med Microsoft.Data.SqlClient.
- Azure Key Vault och Microsoft.Data.SqlClient har ingen nyckellagring.
- Microsoft.Data.SqlClient stöder inte Always Encrypted för säkra enklaver.
- Endast .NET Framework och .NET Core stöder Always Encrypted, .NET Standard gör det inte, eftersom .NET Standard saknar vissa krypteringsberoenden.
Originallänk:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Publicerad på 2021-12-27 22:21:14
|
|
|
