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

The main content of this article is to explain "what problems to pay attention to in dealing with ADO.NET standardization", interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what problems to pay attention to in dealing with ADO.NET standardization"!

At first glance, the model provided by ADO.NET is fragmented because it does not contain a passing set of objects to handle many different types of databases. Although different .NET data providers use different classes, all providers are standardized in the same way. To be more specific, each provider is based on the same base class and interface set. For example, each connection object executes IDbConnection interfaces that define core methods such as Open () and Close (). This standardization ensures that each connection class works in the same way and that the core properties and method sets provided to the user are the same.

After the visual interface, different providers use completely different underlying calls and API. For example, the ADO.NET standardized SQL Server provider uses the private TDS (Tabular Data Stream) protocol to communicate with the server. The benefits of this model are not obvious, but they are important:

Because each provider uses the same interface and base class, you can write generic data access code (with a little effort) instead of writing code for a specific provider class. You will see the role of this technology in the "Provider-Agnostic Code" section.

Since the implementation of each provider is completely separate, ADO.NET standardization can use proprietary optimization measures (unlike the ADO model. In ADO, ADO.NET standardizes that each database call needs to be filtered using the passed layer before reaching the underlying database driver. In addition, custom providers can add non-standard functionality to extend deficiencies in other providers (such as the ability of SQL Server to perform XML queries).

ADO.NET also has another standard layer: DataSet. DataSet is a data container that meets all requirements, and the data comes from one or more tables of a data source. DataSet is very generic; in other words, custom providers do not need to define a custom version of the DataSet class. No matter which data provider you use, you can extract data and put it into an unconnected DataSet in the same way. ADO.NET standardization makes the data acquisition code separate from the data processing code. If you change the underlying database, you only need to change the data acquisition code, but if you use the DataSet and your information have the same structure, you do not need to change the data processing method.

At this point, I believe that you have a deeper understanding of "what issues to pay attention to in dealing with ADO.NET standardization", you might as well come to the actual operation! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.