Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the changes of System.Data in .NET Core 3.0. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Although System.Data does not attract much attention, in .NET, System.Data is very important for the connection of various relational databases. System.Data is also known as ADO.NET, and its predecessor is ActiveX Data Objects. System.Data provides a framework on which .NET data-driven applications can be built. This framework also provides some conventions that data drivers should follow.

Connections,commands,data readers is double inheritance. Each implements the basic functions from DbConnection and DbCommand,DbDataReader respectively. They also implement abstract interfaces IDbConnection, IDbCommand, and IDbDataReader, which enable them to support simulated scenarios and non-traditional data sources. The underlying classes described below are all based on the double inheritance scheme.

Although connection strings is generally considered a string, some tools think of it as an object that inherits from DbConnectionStringBuilder. It can handle specific parsing of database connection strings and help developers better understand the available settings for a particular database.

System.Data predates the ORM framework in .NET, but by implementing DbDataAdapter and DbCommandBuilder, it provides a common way to generate sql. It can be used directly or in combination with normal and typed datasets.

If you want to find an example of an abstract factory pattern, you can look at DbProviderFactory. Its self-mine provides connections, commands, command parameters, command builders, data adapters. It contains all the data access requirements you need, not just the logic of the database.

Problems with the interface

As mentioned above, System.Data relies on double inheritance. This will cause problems when we want to add new methods. For example, asynchronous operations are added to the DbCommand in .NET 4.5. But they cannot be added to the matching IDbCommand interface, because this would be a destructive change. This means that you cannot use both asynchronous operations and abstract interfaces that are easy to simulate.

Microsoft could have redesigned the abstract interface in .NET Core 1.0 to match the abstract class (Java is already implemented through the JDBC interface). However, this makes it difficult for .NET Framework to share source code.

In theory, this feature can be used to adjust the interface in a backward-compatible manner if the default interface method can appear in Category 8.0. However, it is not compatible in the .NET Framework because the default interface method is only a feature of the .NET Core. It also cannot use older compilers and other .NET languages.

String overloading in DbDataReader.Get ()

Our first feature of System.Data in .NET Core 3.0 is the ability to pass column names in the Get () method of DbDataReader. People have long complained that this interface cannot refer to columns by name. This means that you need to use this mode.

1reader.GetInt32 (reader.GetOrdinal ("columnName"))

An obvious (and for some people, long overdue) simplification is to provide string overloading.

1reader.GetInt32 ("columnName")

This has been implemented in Oracle's Connector/NET and MySqlConnector.

For performance reasons, this method is not marked as a virtual method, allowing the JIT compiler to easily inline it. Also for the above reasons, the new method set will not be added to the IDbDataReader.

XmlDataDocument

If you know the history of XmlDataDocument, this seems like a strange choice. In the 2010 release of .NET 4.0, it was marked as obsolete and warned that XmlDataDocument would be removed in future releases. The reason for using it now is that some WinForms and WPF applications use it, and according to the bug report, it has a usage rate of 1-7% in various categories of Apiport.

DatasetExtensions

DataTableExtensions will no longer be supported in .NET Core 3. Although it looks like a class with six extension methods, we cannot build the AsDataView method without modifying the System.Data. The reasons are quite complex, involving internal methods, type forwarding, and the challenges posed by the .NET Standard.

This is what the editor shares with you about the changes in System.Data in .NET Core 3.0. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.