arrière-plan
Aux débuts de .NET, le cadre System.Data était un composant important. Il offre un moyen de créer des pilotes de base de données .NET, similaire aux objets de données ActiveX de Visual Basic. Bien que l’API soit différente, son nom est réutilisé, d’où le surnom ADO .NET.
Une différence clé entre ADO et ADO .NET (c’est-à-dire System.Data) est le modèle d’objet. Dans ADO, il suffit généralement d’utiliser les objets Connection, Command et Recordset, et le pilote OleDB/ODBC masque autre chose. Cela améliore la réutilisation du code, mais il est difficile pour les développeurs d’exposer certaines fonctionnalités de base de données.
Dans ADO .NET, vous pouvez aussi utiliser OleDB/ODBC, mais dans la plupart des cas, vous utiliserez une série de classes spécifiques à la base de données. Ces classes sont dérivées de DBConnection, DBCommann et DBDataReader, qui maintiennent la réutilisabilité du code original. Mais comme ils sont des types fortement nommés, ils doivent faire explicitement partie de la bibliothèque .NET.
Probablement pour simplifier le développement, SQL Server, OleDB et ODBC font tous partie du cadre System.Data. Cette approche était acceptable à l’époque, mais elle a posé problème au cycle actuel de développement de SQL Server.
En fait, les cycles de publication de SQL Server sont passés de 3 à 5 ans à presque tous les ans. Les nouvelles versions nécessitent souvent des mises à jour du pilote .NET, ce qui n’est pas possible s’il est lié au cycle de sortie standard .NET.
La première étape consiste à diviser la bibliothèque System.Data. NET Core accomplit cette étape en fournissant des bibliothèques distinctes pour chaque pilote de base de données. L’étape suivante consiste à séparer complètement le pilote SQL Server de .NET Core/Standard. Pour ce faire, ils ont créé Microsoft.Data.SqlClient.
Mise à jour vers Microsoft.Data.SqlClient
Pour la plupart des développeurs, utiliser Microsoft.Data.SqlClient sera très simple, il suffit de modifier l’instruction using en haut de chaque classe. De plus, il utilise les mêmes noms de classes et API, et offre à peu près les mêmes fonctionnalités.
Pour les ORM légers comme Dapper ou RepoDB, aucun autre changement n’est nécessaire.
Si les développeurs utilisent des ORM pour gérer les connexions (par exemple, EF, NHibernate), ils doivent attendre les mises à jour des ORM.
Les plus problématiques sont celles qui mélangent les ORM. Si un ORM utilise Microsoft.Data.SqlClient et l’autre System.Data.SqlClient, cela ne fonctionnera pas en même temps. C’est particulièrement important lorsqu’on travaille avec des objets SqlTransaction partagés.
Utilisabilité
La version 1.0 de Microsoft.Data.SqlClient est disponible sur les plateformes suivantes :
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Problèmes connus
Tout le monde n’a pas besoin de passer à niveau immédiatement. Ces problèmes connus sont notés dans la documentation :
- Le Type de données utilisateur (UDT) peut ne pas fonctionner avec Microsoft.Data.SqlClient.
- Azure Key Vault et Microsoft.Data.SqlClient n’ont pas de stockage de clés.
- Microsoft.Data.SqlClient ne prend pas en charge Always Encrypted pour les enclaves sécurisées.
- Seuls .NET Framework et .NET Core supportent Always Encrypted, .NET Standard ne le fait pas, car .NET Standard manque de certaines dépendances de chiffrement.
Lien original :https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Publié sur 27/12/2021 22:21:14
|
|
|
