bakgrunn
I de tidlige dagene av .NET var System.Data-rammeverket en viktig komponent. Den gir en måte å lage .NET-databasedrivere på, lik Visual Basics ActiveX Data Objects. Selv om API-et er annerledes, er navnet gjenbrukt, derav kallenavnet ADO .NET.
En viktig forskjell mellom ADO og ADO .NET (dvs. System.Data) er objektmodellen. I ADO trenger du vanligvis bare å bruke Connection-, Command- og Recordset-objektene, og OleDB/ODBC-driveren skjuler noe annet. Dette forbedrer gjenbruk av kode, men det er vanskelig for utviklere å eksponere noen databasefunksjoner.
I ADO .NET kan du også bruke OleDB/ODBC, men i de fleste tilfeller vil du bruke en serie databasespesifikke klasser. Disse klassene er avledet fra DBConnection, DBCommand, og DBDataReader, som opprettholder gjenbrukbarheten til den opprinnelige koden. Men fordi de er sterkt navngitte typer, må de eksplisitt være en del av .NET-biblioteket.
Sannsynligvis for å forenkle utviklingen, er SQL Server, OleDB og ODBC-drivere alle en del av System.Data-rammeverket. Denne tilnærmingen var akseptabel på den tiden, men skapte problemer i den nåværende utviklingssyklusen for SQL Server.
Faktisk har SQL Server-utgivelsessykluser endret seg fra 3 til 5 år til nesten hvert år. Nye utgivelser krever ofte oppdateringer av .NET-driveren, noe som ikke er mulig hvis den er knyttet til .NETs standardutgivelsessyklus.
Det første steget er å dele System.Data-biblioteket. NET Core oppnår dette trinnet ved å tilby separate biblioteker for hver databasedriver. Neste steg er å fullstendig skille SQL Server-driveren fra .NET Core/Standard. For å gjøre dette opprettet de Microsoft.Data.SqlClient.
Oppgrader til Microsoft.Data.SqlClient
For de fleste utviklere vil det være veldig enkelt å bruke Microsoft.Data.SqlClient, bare å endre using statement øverst i hver klasse. I tillegg bruker det de samme klassenavnene og API-ene, og tilbyr omtrent de samme funksjonene.
For lette ORM-er som Dapper eller RepoDB kreves det ingen ytterligere endringer.
Hvis utviklere bruker ORM-er for å administrere tilkoblinger (f.eks. EF, NHibernate), må de vente på ORM-oppgraderinger.
De mest problematiske er de som blander ORM-er. Hvis én ORM bruker Microsoft.Data.SqlClient og den andre bruker System.Data.SqlClient, vil det ikke fungere samtidig. Dette er spesielt viktig når man jobber med delte SqlTransaction-objekter.
Brukervennlighet
Versjon 1.0 av Microsoft.Data.SqlClient er tilgjengelig for disse plattformene:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Kjente problemer
Ikke alle trenger å oppgradere med en gang. Disse kjente problemene er notert i dokumentasjonen:
- User Data Type (UDT) fungerer kanskje ikke med Microsoft.Data.SqlClient.
- Azure Key Vault og Microsoft.Data.SqlClient har ikke et nøkkellager.
- Microsoft.Data.SqlClient støtter ikke Always Encrypted for sikre enklaver.
- Kun .NET Framework og .NET Core støtter Always Encrypted, .NET Standard gjør det ikke, fordi .NET Standard mangler noen krypteringsavhengigheter.
Original lenke:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Publisert på 27.12.2021 22:21:14
|
|
|
