Figure 1 shows that the layer is usually based on HTML output, and can work well with any newer browser. The web page is built on the web server using Active Server Pages (ASP), and only at some of the considerable circumstances are tried to provide the actual functionality of the browser through COM, dynamic HTML, and XML support. The key is the intermediate layer, which typically has one or more business objects to obtain and exchange data to respond to the user's input. These components may need to pass data from each other, and they need to be easy to use, powerful and powerful and for all components. The ADO record set (ADO representation of the table or view) is a quite a good solution. The flexibility of ADO records is enough to allow you to locate records and use filters and bookmarks. They also provide functions such as sorting, automatic paging, and persistence, and work at time with the data source. The record set can be collected in a multi-layer. However, only COM objects can use the ADO recordset. This is suitable in the Single Sub-architecture that COM / DCOM in the business layer. However, when heterogeneous nodes such as a large machine or a UNIX platform will bring a lot of inconvenience. In the programmable web era requires a programming interface that can simultaneously across various platforms, but current ADOs, especially record sets, is a powerful tool for manipulating data in Windows and COM-based schemes. As the system gradually evolved in a complete internet interoperability, they gradually lost their attraction.
In perfect cases, data should be accessed in any platform or device, and have the same flexibility. Thus, each platform or device can freely manipulate data as needed. However, if you record the set operation data through the ADO, you will be in limited interoperability. Currently, if you access the data via ADO, you want to transfer it to remote components, or use the same ADO recordset obtained from the data access module, and convert it to another thing that can be transmitted through the network, the most important Yes, it can be understood in its ultimate destination. The record set requires COM collection. For example, COM call is not always able to pass through the company's firewall. In addition, when collecting the ADO record set, a large part of the total processing time is used to complete the necessary type conversion. In fact, it is important to ensure that all values in the record are mapped to COM to identify and know how to process the valid data type. When the relevant components are physically separate and run on different machines, COM aggressive factors become more important. Therefore, in the process of moving the world that is fully connected by the Internet, the current Windows data species along with the ADO record set must continue to exist. The ADO needs to be changed to be due to the interaction of cross-platform modules require a universal data model. In addition, we don't want this to change too much, the reason is that there are still a number of good features in ADO, and give up them are a unfortunate thing. We need to extract the essence of the ADO record set and re-construct it into another thing that can be conveniently transmitted and processed on any platform. HTTP provides a widely accepted network channel for most people. XML sets together the infrastructure described in the widely accepted data. ADO.NET is a smaller improvement to ADO, which makes it a variety of standard programming models for creating distributed and data sharing applications.
All the basic principles and roots of all ADO.NET objects are DataSet object models.
DataSet is an extension of the ADO recordset. DataSet is a database view that is simple, independent, existing in memory. If there is no restriction condition between a DataSet and the data source, the DataSet in this case can be created dynamically. DataSet uses some functions added to the ADO record set: the ability to work when disconnect or use a variety of data types to populate and create applications. A DataSet can contain any number of tables, usually (but not always) corresponding to a database table or view. A table (DataTable object) is a collection of rows and columns, each of which retains its original state and its current state. The ADO record set is often seen as a high-level array form. Similarly, DataSet is a super recordset that provides the following features:
☆ A better and richer programming interface for accommodating data;
☆ A object model for providing more generalized data views;
☆ An XML-based standard console for input and output.
The ADO recordset is basically a (probably a hierarchical) record collection, which has some specific methods for completing some specific functions. These include rolling, sorting, filtering, bookmarks. The recordset is essentially a copy of the table in memory. DataSet looks more like SQL Server or Access database, which is an entity containing more tables, specific views, and foreign key relationships. The DataSet object model reflects this larger range that allows you to view a number of available data across multiple data sheets, relationships, extended properties, and rows, and can also be used to explain non-persistent data or from another durable The data of the storage medium is stored.
The ADO record set allows the content to be saved to XML and rebuilds the content from an external XML file. However, the default XML architecture used is optimized for the export / imported ADO recordset, rather than exchange of actual data. The ADO XML architecture contains many information about column types and locations and other metadata. If you want to rebuild a recordset from a XML document, this information is critical, but if you just want to deliver data and make the recipient use it, this information is not used. With DataSet, XML architecture is more refined because the objects are not directly related to the relational database, although the object can be used to reproduce the database. DataSet describes the data, while the ADO record set describes a record collection that is acquired by a table. This is the attraction of the ADO.NET data model.
The ADO.NET XML architecture is only responsible for reproducing the table and the definition of the data set, and the responsibility to build a DataSet object is completed when the ADO.NET is running. The ADO XML format is unable to realize interoperability due to it is too specific. Also because it is too cumbersome, it will not be able to collect if data compressed artificial intervention is not performed. In the DataSet architecture, the data can be safely transmitted from one layer to another.
