fundo
Nos primeiros dias do .NET, o framework System.Data era um componente importante. Ele oferece uma forma de criar drivers de banco de dados .NET, semelhante aos Objetos de Dados ActiveX do Visual Basic. Embora a API seja diferente, seu nome é reutilizado, daí o apelido ADO .NET.
Uma diferença chave entre ADO e ADO .NET (ou seja, System.Data) é o modelo de objetos. No ADO, normalmente você só precisa usar objetos Connection, Command e Recordset, e o driver OleDB/ODBC esconde outra coisa. Isso melhora o reuso do código, mas é difícil para os desenvolvedores exporem alguns recursos do banco de dados.
No ADO .NET, você também pode usar OleDB/ODBC, mas na maioria dos casos usará uma série de classes específicas para banco de dados. Essas classes são derivadas de DBConnection, DBCommann e DBDataReader, que mantêm a reutilização do código original. Mas, como são tipos fortemente nomeados, precisam fazer parte explicitamente da biblioteca .NET.
Provavelmente para simplificar o desenvolvimento, SQL Server, OleDB e drivers ODBC fazem parte do framework System.Data. Essa abordagem era aceitável na época, mas criou problemas com o ciclo atual de desenvolvimento do SQL Server.
Na verdade, os ciclos de lançamento do SQL Server mudaram de 3 a 5 anos para quase todos os anos. Novos lançamentos frequentemente exigem atualizações no driver .NET, o que não é possível se estiver atrelado ao ciclo de lançamento padrão .NET.
O primeiro passo é dividir a biblioteca System.Data. O NET Core realiza essa etapa fornecendo bibliotecas separadas para cada driver de banco de dados. O próximo passo é separar completamente o driver do SQL Server do .NET Core/Standard. Para isso, criaram o Microsoft.Data.SqlClient.
Atualize para Microsoft.Data.SqlClient
Para a maioria dos desenvolvedores, usar Microsoft.Data.SqlClient será muito simples, apenas modificando a instrução using no topo de cada classe. Além disso, ele usa os mesmos nomes de classes e APIs, e oferece aproximadamente as mesmas funcionalidades.
Para ORMs leves como Dapper ou RepoDB, não são necessárias mais alterações.
Se desenvolvedores usam ORMs para gerenciar conexões (por exemplo, EF, NHibernate), eles precisam esperar por atualizações de ORM.
Os mais problemáticos são aqueles que misturam ORMs. Se um ORM usa Microsoft.Data.SqlClient e o outro usa System.Data.SqlClient, ele não funcionará ao mesmo tempo. Isso é especialmente importante ao trabalhar com objetos SqlTransaction compartilhados.
usabilidade
A versão 1.0 do Microsoft.Data.SqlClient está disponível para as seguintes plataformas:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Questões conhecidas
Nem todo mundo precisa atualizar imediatamente. Esses problemas conhecidos estão apontados na documentação:
- O Tipo de Dado do Usuário (UDT) pode não funcionar com o Microsoft.Data.SqlClient.
- Azure Key Vault e Microsoft.Data.SqlClient não possuem um key store.
- O Microsoft.Data.SqlClient não suporta o Always Encrypted para enclaves seguros.
- Apenas o .NET Framework e o .NET Core suportam Always Encrypted, o .NET Standard não suporta, porque o .NET Standard não possui algumas dependências de criptografia.
Link original:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Publicado em 27/12/2021 22:21:14
|
|
|
