fondo
En los primeros días de .NET, el framework System.Data era un componente importante. Proporciona una forma de crear controladores de bases de datos .NET, similar a los Objetos de Datos ActiveX de Visual Basic. Aunque la API es diferente, su nombre se reutiliza, de ahí el apodo ADO .NET.
Una diferencia clave entre ADO y ADO .NET (es decir, System.Data) es el modelo de objetos. En ADO, normalmente solo necesitas usar objetos Connection, Command y Recordset, y el controlador OleDB/ODBC oculta otra cosa. Esto mejora la reutilización del código, pero es difícil para los desarrolladores exponer algunas características de la base de datos.
En ADO .NET, también puedes usar OleDB/ODBC, pero en la mayoría de los casos usarás una serie de clases específicas de base de datos. Estas clases derivan de DBConnection, DBCommann y DBDataReader, que mantienen la reutilización del código original. Pero como son tipos con nombres fuertes, deben formar parte explícitamente de la biblioteca .NET.
Probablemente para simplificar el desarrollo, SQL Server, OleDB y los controladores ODBC forman parte del framework System.Data. Este enfoque era aceptable en su momento, pero creó problemas con el ciclo actual de desarrollo de SQL Server.
De hecho, los ciclos de lanzamiento de SQL Server han cambiado de 3 a 5 años a casi todos los años. Las nuevas versiones a menudo requieren actualizaciones al controlador .NET, lo cual no es posible si está vinculado al ciclo de lanzamiento estándar .NET.
El primer paso es separar la biblioteca System.Data. NET Core realiza este paso proporcionando librerías separadas para cada controlador de base de datos. El siguiente paso es separar completamente el controlador de SQL Server de .NET Core/Standard. Para ello, crearon Microsoft.Data.SqlClient.
Actualizar a Microsoft.Data.SqlClient
Para la mayoría de desarrolladores, usar Microsoft.Data.SqlClient será muy sencillo, simplemente modificando la sentencia using en la parte superior de cada clase. Además, utiliza los mismos nombres de clase y APIs, y ofrece más o menos las mismas características.
Para ORMs ligeros como Dapper o RepoDB, no se requieren más cambios.
Si los desarrolladores usan ORMs para gestionar conexiones (por ejemplo, EF, NHibernate), deben esperar a las actualizaciones de ORM.
Los más problemáticos son los que mezclan ORMs. Si un ORM usa Microsoft.Data.SqlClient y el otro System.Data.SqlClient, no funcionará al mismo tiempo. Esto es especialmente importante al trabajar con objetos SqlTransaction compartidos.
usabilidad
La versión 1.0 de Microsoft.Data.SqlClient está disponible para estas plataformas:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Problemas conocidos
No todo el mundo necesita actualizar de inmediato. Estos problemas conocidos se señalan en la documentación:
- El tipo de dato de usuario (UDT) puede no funcionar con Microsoft.Data.SqlClient.
- Azure Key Vault y Microsoft.Data.SqlClient no tienen un almacén de claves.
- Microsoft.Data.SqlClient no soporta Always Encrypted para enclaves seguros.
- Solo .NET Framework y .NET Core soportan Always Encrypted, .NET Standard no lo hace, porque .NET Standard carece de algunas dependencias de cifrado.
Enlace original:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Publicado en 27/12/2021 22:21:14
|
|
|
