Apesar de não receber muita atenção, o System.Data é crucial para qualquer tipo de acesso em banco de dados relacional no .NET. Também conhecido como ADO.NET em homenagem ao seu predecessor, o ActiveX Data Objects, o System.Data fornece uma arquitetura genérica dentro da qual os drivers de banco de dados .NET podem ser criados. Essa arquitetura fornece certas convenções às quais os drivers de banco de dados devem aderir.
Conexões, comandos e leitores de dados são todos baseados em um esquema de herança dupla. Cada um herda algumas funcionalidades básicas de DbConnection, DbCommand e DbDataReader, respectivamente. Eles também implementam as interfaces abstratas IDbConnection, IDbCommand e IDbDataReader, que permitem cenários de simulação e origens de dados não tradicionais. Esse esquema de herança dupla também é usado para todas as classes base descritas a seguir.
Enquanto strings de conexão normalmente são consideradas como strings, existem recursos para representá-los como objetos que herdam o DbConnectionStringBuilder. Isso lida com análise específica de banco de dados de strings de conexão e dá ao desenvolvedor uma idéia melhor de quais configurações estão disponíveis para um banco de dados específico.
O System.Data antecede os ORMs para .NET, mas oferece uma maneira genérica de gerar código SQL por meio de implementações das classes DbDataAdapter e DbCommandBuilder. Isso foi usado tanto diretamente como em conjunto com DataSets tipados e normais.
Se estiver procurando um exemplo real do pattern de fábrica abstrata, examine o DbProviderFactory. Subclasses dele fornecem conexões, comandos, parâmetros de comandos, construtores de comandos e adaptadores de dados. Essencialmente, há tudo o que se precisa para acessar dados sem a necessidade de lógica específica do banco de dados.
O problema com interfaces
Como mencionado, o System.Data depende de herança dupla. Isso pode ser problemático ao adicionar novos métodos. Por exemplo, operações assíncronas foram adicionadas ao DbCommand no .NET 4.5. No entanto, estas não puderam ser adicionadas à interface IDbCommand correspondente, pois isso seria uma alteração significativa. Isso, por sua vez, significa que não se pode usar, ao mesmo tempo, operações assíncronas e a interface abstrata (que pode ser simulada facilmente em testes).
A Microsoft poderia ter feito uma "reinicialização" única das interfaces abstratas no .NET Core 1.0 para corresponderem às classes abstratas (a linguagem Java já fez isso no passado com interfaces JDBC). No entanto, isso dificultaria o compartilhamento de código com o .NET Framework.
Se os métodos de interface padrão vierem no C# 8, então, em teoria, poderiam ser usados para realinhar as interfaces de maneira compatível com versões anteriores. Mas, novamente, isso não seria compatível com o .NET Framework, já que os métodos de interface padrão são um recurso somente do .NET Core. Nem funcionaria com compiladores antigos e com outras linguagens .NET.
String Overloads para DbDataReader.Get*() #31595
Nosso primeiro recurso do .NET Core 3.0 é a capacidade de passar um nome de coluna para os métodos DbDataReader.GetXXX. Uma queixa antiga sobre essa interface é que não se pode refinar as colunas pelo nome. O que significa que é preciso usar o seguinte padrão de código:
reader.GetInt32(reader.GetOrdinal("columnName"))
Uma simplificação óbvia (e para alguns, bastante atrasada) é oferecer uma sobrecarga recebendo string.
reader.GetInt32("columnName")
Isso já foi feito no Connector/NET e no MySqlConnector, ambos da Oracle.
Por motivos de desempenho, esse novo método não será marcado como virtual, permitindo que o compilador JIT faça o inlining facilmente. Assim, pelas razões mencionadas, o novo conjunto de métodos não será adicionado a IDbDataReader.
XmlDataDocument #33442
Caso conheça a história do XmlDataDocument, pode parecer uma escolha estranha, pois a classe foi marcada como obsoleta com o aviso "A classe XmlDataDocument será removida em uma versão futura", desde que o .NET 4.0 foi lançado em 2010.
A razão pela qual está sendo escolhido agora é que alguns WinForms e aplicativos WPF o utilizam. O relatório de erros diz: "Isso tem 1-7% de uso em várias categorias do Apiport".
DatasetExtensions
Não será disponibilizado no .NET Core 3 a classe DataTableExtensions. Embora pareça bastante simples fazê-lo, já que há apenas seis métodos de extensão, o AsDataView não pode ser construído sem modificações no próprio System.Data. O raciocínio, neste caso, é bastante complexo, tendo a ver com métodos internos, com o encaminhamento de tipos (type forwarding) e com desafios apresentados pelo .NET Standard.
Para o leitor interessado nos detalhes, as discussões relevantes são: