baggrund
I de tidlige dage af .NET var System.Data-rammen en vigtig komponent. Det giver en måde at oprette .NET-databasedrivere på, ligesom Visual Basics ActiveX Data Objects. Selvom API'et er anderledes, genbruges dets navn, deraf kælenavnet ADO .NET.
En væsentlig forskel mellem ADO og ADO .NET (dvs. System.Data) er objektmodellen. I ADO behøver du som regel kun bruge Connection-, Command- og Recordset-objekter, og OleDB/ODBC-driveren skjuler noget andet. Dette forbedrer genbrug af kode, men det er svært for udviklere at eksponere nogle databasefunktioner.
I ADO .NET kan du også bruge OleDB/ODBC, men i de fleste tilfælde vil du bruge en række database-specifikke klasser. Disse klasser stammer fra DBConnection, DBCommand, og DBDataReader, som opretholder genanvendeligheden af den oprindelige kode. Men fordi de er stærkt navngivne typer, skal de eksplicit være en del af .NET-biblioteket.
Sandsynligvis for at forenkle udviklingen er SQL Server, OleDB og ODBC-drivere alle en del af System.Data-rammeværket. Denne tilgang var acceptabel på det tidspunkt, men skabte problemer i den nuværende udviklingscyklus af SQL Server.
Faktisk er SQL Server-udgivelsescyklusserne ændret fra 3 til 5 år til næsten hvert år. Nye udgivelser kræver ofte opdateringer af .NET-driveren, hvilket ikke er muligt, hvis den er bundet til .NET-standardudgivelsescyklussen.
Det første skridt er at opdele System.Data-biblioteket. NET Core opnår dette trin ved at levere separate biblioteker til hver databasedriver. Næste skridt er fuldstændigt at adskille SQL Server-driveren fra .NET Core/Standard. For at gøre dette skabte de Microsoft.Data.SqlClient.
Opgrader til Microsoft.Data.SqlClient
For de fleste udviklere vil det være meget simpelt at bruge Microsoft.Data.SqlClient, blot ved at ændre using statement øverst i hver klasse. Derudover bruger det de samme klassenavne og API'er og tilbyder omtrent de samme funktioner.
For lette ORM'er som Dapper eller RepoDB kræves der ingen yderligere ændringer.
Hvis udviklere bruger ORM'er til at administrere forbindelser (f.eks. EF, NHibernate), skal de vente på ORM-opgraderinger.
De mere besværlige er dem, der blander ORM'er. Hvis den ene ORM bruger Microsoft.Data.SqlClient og den anden bruger System.Data.SqlClient, vil det ikke fungere samtidig. Dette er især vigtigt, når man arbejder med delte SqlTransaction-objekter.
brugervenlighed
Version 1.0 af Microsoft.Data.SqlClient er tilgængelig til disse platforme:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Kendte problemer
Ikke alle behøver at opgradere med det samme. Disse kendte problemer er noteret i dokumentationen:
- User Data Type (UDT) fungerer muligvis ikke med Microsoft.Data.SqlClient.
- Azure Key Vault og Microsoft.Data.SqlClient har ikke et nøglelager.
- Microsoft.Data.SqlClient understøtter ikke Altid Krypteret for sikre enklaver.
- Kun .NET Framework og .NET Core understøtter Always Encrypted, .NET Standard gør ikke, fordi .NET Standard mangler nogle krypteringsafhængigheder.
Originalt link:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Opslået på 27/12/2021 22.21.14
|
|
|
