sfondo
Nei primi giorni di .NET, il framework System.Data era un componente importante. Fornisce un modo per creare driver di database .NET, simile agli ActiveX Data Objects di Visual Basic. Sebbene l'API sia diversa, il suo nome viene riutilizzato, da cui il soprannome ADO .NET.
Una differenza chiave tra ADO e ADO .NET (cioè System.Data) è il modello oggetto. In ADO, di solito devi usare solo gli oggetti Connection, Command e Recordset, e il driver OleDB/ODBC nasconde qualcos'altro. Questo migliora il riutilizzo del codice, ma è difficile per gli sviluppatori esporre alcune funzionalità del database.
In ADO .NET puoi anche usare OleDB/ODBC, ma nella maggior parte dei casi userai una serie di classi specifiche per database. Queste classi derivano da DBConnection, DBCommann e DBDataReader, che mantengono la riutilizzabilità del codice originale. Ma poiché sono tipi fortemente denominati, devono essere esplicitamente parte della libreria .NET.
Probabilmente per semplificare lo sviluppo, SQL Server, OleDB e driver ODBC fanno tutti parte del framework System.Data. Questo approccio era accettabile all'epoca, ma creò problemi con l'attuale ciclo di sviluppo di SQL Server.
In effetti, i cicli di rilascio di SQL Server sono cambiati da 3-5 anni a quasi ogni anno. Le nuove versioni spesso richiedono aggiornamenti al driver .NET, cosa impossibile se legata al ciclo di rilascio dello standard .NET.
Il primo passo è dividere la libreria System.Data. NET Core realizza questo passaggio fornendo librerie separate per ogni driver di database. Il passo successivo è separare completamente il driver SQL Server da .NET Core/Standard. Per farlo, hanno creato Microsoft.Data.SqlClient.
Aggiorna a Microsoft.Data.SqlClient
Per la maggior parte degli sviluppatori, usare Microsoft.Data.SqlClient sarà molto semplice, basta modificare l'istruzione using in cima a ogni classe. Inoltre, utilizza gli stessi nomi di classe e API, e offre più o meno le stesse funzionalità.
Per ORM leggeri come Dapper o RepoDB, non sono necessarie ulteriori modifiche.
Se gli sviluppatori usano gli ORM per gestire le connessioni (ad esempio, EF, NHibernate), devono aspettare gli aggiornamenti degli ORM.
I più problematici sono quelli che mescolano gli ORM. Se un ORM usa Microsoft.Data.SqlClient e l'altro System.Data.SqlClient, non funzionerà contemporaneamente. Questo è particolarmente importante quando si lavora con oggetti SqlTransaction condivisi.
usabilità
La versione 1.0 di Microsoft.Data.SqlClient è disponibile per queste piattaforme:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Problemi noti
Non tutti hanno bisogno di aggiornare subito. Questi problemi noti sono riportati nella documentazione:
- Il Tipo di Dati utente (UDT) potrebbe non funzionare con Microsoft.Data.SqlClient.
- Azure Key Vault e Microsoft.Data.SqlClient non hanno uno store delle chiavi.
- Microsoft.Data.SqlClient non supporta Always Encrypted per enclave sicure.
- Solo .NET Framework e .NET Core supportano Always Encrypted, .NET Standard non lo fa, perché .NET Standard manca di alcune dipendenze di crittografia.
Link originale:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Pubblicato su 27/12/2021 22:21:14
|
|
|
