背景

在 .NET创建之初，System.Data框架是一个重要的组件。它为创建 .NET数据库驱动程序提供了一种方式，类似Visual Basic的ActiveX Data Objects。虽然API不一样，但重用了它的名称，所以才有了ADO .NET这个绰号。

ADO和ADO .NET（即System.Data）之间的一个关键区别是对象模型。在ADO中，通常只需要使用Connection、Command和Recordset对象，OleDB/ODBC驱动程序隐藏掉了其他东西。这提高了代码复用率，但开发人员难以将一些数据库特性暴露出来。

在ADO .NET中，你也可以使用OleDB/ODBC，但在大多数情况下会使用一系列特定于数据库的类。这些类派生自DBConnection、DBCommand和DBDataReader，可以保持原来的代码复用性。但因为它们是强命名类型，需要显式地作为 .NET库的一部分。

可能是为了简化开发，SQL Server、OleDB和ODBC驱动程序同时作为System.Data框架的一部分。这种方式在当时是可以接受的，但却给现在的SQL Server开发周期带来了问题。

实际上，SQL Server的发布周期已经从3年到5年变成了几乎每年一次。发布的新版本通常需要更新 .NET驱动程序，如果它被绑定到 .NET标准发布周期中，这就不可能及时发布。

第一步是拆分System.Data库。 .NET Core完成了这一步，为每个数据库驱动程序提供了单独的库。下一步是将SQL Server驱动程序与 .NET Core/Standard完全分离。为此，他们创建了Microsoft.Data.SqlClient。

升级到Microsoft.Data.SqlClient

对于大多数开发人员来说，使用Microsoft.Data.SqlClient将会变得非常简单，只需要修改每个类顶部的using语句即可。另外，它使用了相同的类名和API，并提供了大致相同的特性。

对于轻量级ORM，如Dapper或RepoDB，不需要做进一步的改动。

如果开发人员使用ORM来管理连接（例如EF、NHibernate），就需要等待ORM升级。

比较麻烦的是那些混合ORM。如果一个ORM使用了Microsoft.Data.SqlClient，而另一个使用了System.Data.SqlClient，就不能同时正常运行。这在使用共享SqlTransaction对象时尤为重要。

1.0版Microsoft.Data.SqlClient可用于这些平台:

并不是每个人都需要马上升级。文档中指出了这些已知问题:

用户数据类型（UDT）可能无法与Microsoft.Data.SqlClient一起使用。
Azure Key Vault和Microsoft.Data.SqlClient没有密钥存储。
Microsoft.Data.SqlClient不支持安全飞地的Always Encrypted。
只有 .NET Framework和 .NET Core支持Always Encrypted， .NET Standard不支持，因为 .NET Standard缺少某些加密依赖项。

原文链接：