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

This article is to share with you about the database-driven framework System.Data in .NET Core 3.0. the editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

Although it doesn't get a lot of attention, System.Data is critical to accessing any relational database in .NET. Because its predecessor is ActiveX Data Objects, it is also called ADO.NET. System.Data provides a general framework that is the basis for building A. NET database driver The framework provides specific specifications that database drivers can follow.

Connections, commands, and data readers are all based on dual inheritance mode. They inherit some basic functionality from DbConnection, DbCommand, and DbDataReader, respectively. They also implement abstract interfaces IDbConnection, IDbCommand, and IDbDataReader that can simulate scenarios and non-traditional data sources. This double inheritance mode also applies to all base classes described below.

Although connection strings are generally treated as strings, there are tools that can represent them as objects inherited from DbConnectionStringBuilder. This handles connection string parsing for a specific database and gives developers a better understanding of the settings provided by a particular database.

System.Data predates ORMs for .NET, but it does provide a common way to generate SQL by implementing DbDataAdapter and DbCommandBuilder classes. This can be used either directly or in combination with normal and typed datasets.

If you are looking for a real example of an abstract factory pattern, check out DbProviderFactory. Its subclasses provide connections, commands, command parameters, command builders, and data adapters. Basically everything needed for data access, without the need for database-specific logic.

Problems with the interface

As mentioned above, System.Data relies on double inheritance. This can be a problem when adding new methods. For example, DbCommand in .NET 4.5 adds asynchronous operations. However, they cannot be added to the corresponding 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 reset the abstract interface once in .NET Core 1.0 to match the abstract class (Java has done this in the JDBC interface in the past). However, this makes it difficult to share code with the .NET Framework.

If C# 8 contains default interface methods, you can theoretically use them to reassemble interfaces in a backward-compatible manner. However, because the default interface method is a feature unique to. NET Core, it is not compatible with the .NET Framework and cannot be used with older compilers and other .NET languages.

DbDataReader.Get () string overload # 31595*

The first feature of .NET Core 3.0 is the ability to pass column names to DbDataReader.GetXXX methods. People have long complained that this interface cannot refer to columns by name. This means that you need to use the following mode:

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

Obviously (for some people, it's long overdue), the simplified way is to provide a string overload (string overload):

Reader.GetInt32 ("columnName")

Oracle's Connector/NET and MySqlConnector have already done so.

For performance reasons, this new method will not be marked virtual, making it easy for the JIT compiler to inline it. For the above reasons, the new method set will not be added to the IDbDataReader.

XmlDataDocument # 33442

If you know the history of XmlDataDocument, this seems like a strange choice. Since the release of .NET 4.0 in 2010, it has been marked as obsolete and warned that "XmlDataDocument classes will be removed in future releases."

The reason to start using it again now is that some WinForms and WPF applications are using it. According to the Bug report, "it has 1-7 per cent usage in different categories of Apiport."

DatasetExtensions

One feature that is not available in .NET Core 3 is the DataTableExtensions class. Although it looks very simple, with only six extension methods, you cannot build a System.Data without modifying the AsDataView itself. The reasons are complex, involving internal methods, type forwarding, and the challenges posed by .NET standards.

If you are interested, you can take a look at related topics, including "porting DatasetExtensions to .NET Core # 19771", "porting DataTable.AsDataView extension methods # 27610" and "exposing internal virtual methods that involve key search in DataView # 31764".

This is what the database-driven framework System.Data is like in .NET Core 3.0. the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please 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.