background
In the early days of .NET, the System.Data framework was an important component. It provides a way to create .NET database drivers, similar to Visual Basic's ActiveX Data Objects. Although the API is different, its name is reused, hence the nickname ADO .NET.
One key difference between ADO and ADO .NET (i.e., System.Data) is the object model. In ADO, you usually only need to use Connection, Command, and Recordset objects, and the OleDB/ODBC driver hides something else. This improves code reuse, but it is difficult for developers to expose some database features.
In ADO .NET, you can also use OleDB/ODBC, but in most cases you will use a series of database-specific classes. These classes are derived from DBConnection, DBCommand, and DBDataReader, which maintain the reusability of the original code. But because they are strongly named types, they need to be explicitly part of the .NET library.
Probably to simplify development, SQL Server, OleDB, and ODBC drivers are all part of the System.Data framework. This approach was acceptable at the time, but it created problems with the current SQL Server development cycle.
In fact, SQL Server release cycles have changed from 3 to 5 years to almost every year. New releases often require updates to the .NET driver, which is not possible if it is tied to the .NET standard release cycle.
The first step is to split the System.Data library. NET Core accomplishes this step by providing separate libraries for each database driver. The next step is to completely separate the SQL Server driver from .NET Core/Standard. To do this, they created Microsoft.Data.SqlClient.
Upgrade to Microsoft.Data.SqlClient
For most developers, using Microsoft.Data.SqlClient will be very simple, just modifying the using statement at the top of each class. Plus, it uses the same class names and APIs, and provides roughly the same features.
For lightweight ORMs like Dapper or RepoDB, no further changes are required.
If developers use ORMs to manage connections (e.g., EF, NHibernate), they need to wait for ORM upgrades.
The more troublesome ones are those that mix ORMs. If one ORM uses Microsoft.Data.SqlClient and the other uses System.Data.SqlClient, it won't work at the same time. This is especially important when working with shared SqlTransaction objects.
usability
Version 1.0 of Microsoft.Data.SqlClient is available for these platforms:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Known issues
Not everyone needs to upgrade right away. These known issues are noted in the documentation:
- User Data Type (UDT) may not work with Microsoft.Data.SqlClient.
- Azure Key Vault and Microsoft.Data.SqlClient don't have a key store.
- Microsoft.Data.SqlClient does not support Always Encrypted for secure enclaves.
- Only .NET Framework and .NET Core support Always Encrypted, .NET Standard does not, because .NET Standard lacks some encryption dependencies.
Original link:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Posted on 12/27/2021 10:21:14 PM
|
|
|
