ADO + guided the evolution of data types from ms ii)

What content does ADO + add?

In the most abstract words, ADO + is a more scalable and interoperable ADO. In terms of object model and programming, ADO and ADO + are two completely different entities. Despite this, ADO + originates from ADO and retains its encouraging principles.

The key to enriching ADO with more interoperability and scalability lies in disconnecting this concept. While allowing client script code to implement interesting and interactive functions such as sorting, filtering, and document/view models, the disconnected record set is introduced to ADO 2.0 as a way to retain system resources. Compared with ADO, ADO + has three main advantages: interoperability, enhanced scalability, and strong type. In addition, ADO + facilitates data sharing between data components and navigation between records in tables.

ADO + was designed from the very beginning to operate on disconnected datasets. Disconnected record sets can only benefit applications because they are local views of data and can process and transmit data quickly. ADO + uses XML as a common transmission format. As long as the receiving component runs on a platform with an XML analyzer available, it can provide many features while ensuring interoperability. When transmitting data through XML, the receiver is no longer a COM object. XML is a simple but powerful text-based standard that has been widely accepted by the industry recently. Therefore, it is expected that there will be an XML analysis program on almost every platform. In this way, the receiving component will not have any architecture restrictions. Any pair of software components can share ADO + data as long as they agree to use the same XML architecture for data transmission. Figure 2 illustrates how ADO + applies to the existing architecture.

Figure 2. use ADO + in the DNA solution

The presentation layer can be used or created through Win Forms or Web Forms (these two programming units are dedicated to the Microsoft Visual Studio. NET platform. In either case, all components running on the business layer receive an XML Stream and perform any processing. These components can re-build An ADO + environment, or process the data according to the original XML and make it suitable to be sent to the physical data storage. Business components can obtain ADO + data, convert it to XML, and send it back to the client. Any application that understands XML can intervene in this architecture at any point.

Scalability is the ability of a distributed system to serve a growing number of clients without losing efficiency. Scalability is a term often related to databases, because distributed systems depend heavily on databases. Scalability is a persistent problem for database servers and any software products that encapsulate data access operations. The biggest enemy of scalability is the abuse of key resources. In distributed systems, the key is usually limited. Database Connection is an example of key resources that can affect scalability. The availability of a fixed number of connections imposes an actual limit on the growth of the system and its capabilities. Good software understands this situation and takes appropriate measures to limit its impact. How does ADO + address this problem better than ADO? It is not to say that ADO is not scalable, but that it is to say that the internal use of disconnected and memory tables (which is a feature of ADO +) makes ADO + a solution with greater internal scalability. The reason for its larger scalability is that the disconnected dataset does not keep the lock for a long time or keeps the connection open. If you use ADO, you must write code to obtain this function. If you use ADO +, you will get this function for free.

Using XML as the data transmission language can be more effective than ADO for data sharing. First, bypass the COM collection necessary for COM objects such as record sets so that components can use any set of data types they want to use. This will also bring better performance, because there is no need to ensure that the record complies with the standard COM data type conversion. XML and HTTP also allow data to skip the firewall. Under normal circumstances, the firewall allows HTTP packets to pass through, but will prevent any other content that tries to pass through port 80 rather than port 80.

--------------------------------------------------------------------------------

Components of ADO +

Now I want to introduce the main ADO + objects. We start with the origin of all the content, that is, the DataSet object.

A dataset is the evolution of An ADO record set. The dataset is just a view in the database's disconnected memory. You can have dynamically created datasets and data tables without any information from the database management system (DBMS. In other words, a dataset uses some features that are added to an ADO record set: the ability to work when disconnected, and the ability to create and place data of any type. A dataset can contain any number of tables. Each table usually (but not always) corresponds to a database table or view. The table corresponding to the DataTable object is just a set of rows and columns. Each row retains its original status and current status.

The ADO record set always appears as a common data type that acts as a super array. Similarly, ADO + dataset is a super record set that provides the following functions:

A better and richer programming interface for data storage.

An object model that provides a broader data view without any internal binding with the actual data source.

An XML-based standard console for input and output.
An ADO record set is basically a set of records (which may be hierarchical) with some specific methods for completing some interesting functions. This includes scrolling, sorting, filtering, and bookmarks. The record set is essentially a copy of the table in memory. A dataset looks more like an SQL Server or Access database. It is an entity that contains more tables, specific views, and foreign key relationships.

The DataSet object model reflects this large scope, it allows you to view available data across multiple sets of data tables, relationships, extended attributes, and rows-this can also be used to indicate non-persistent data or just another persistent storage from a database media data.

The ADO record set allows you to save the content to XML and rebuild the content from an external XML file. However, the default XML architecture is optimized for exporting/importing ADO records, rather than for actual data exchange. The ado xml architecture contains a lot of information about the column type, position, and other metadata. This information is crucial if you want to rebuild a record set from an XML document, but if you just want to pass data and use it for the recipient, the information is useless. With ADO + dataset, the XML architecture is more refined, because the indicated object has no direct relationship with the relational database, even though the object can be used to precisely reproduce the database. The ADO + dataset describes the data, while the ADO record set describes a set of records obtained from a table. This is what the ADO + data model looks like.

The ADO + XML architecture only reproduce the relationships defined in tables and datasets. The responsibility for building a DataSet object is left to the ADO + runtime. The ado xml format is too specific to implement real interoperability. It is also too cumbersome to efficiently collect data without manual intervention. There is an underlying similarity between the encouraging principles of the ADO + dataset architecture and the reasons that led to my creation of the JavaScript Recordset object. In both cases, you convert the data description (for example, an XML string) into a platform-specific operation object (that is, a JavaScript Object ). In this process, you securely send your data from one layer to another, regardless of the operating system or software installed.

--------------------------------------------------------------------------------

ADO + command

Although the DataSet object provides a data storage tool in memory, you also need another tool to create and initialize various tables. This tool is a DataSetCommand object, which represents a centralized console that hides the details of connections and commands. The DataSetCommand object allows you to retrieve and save data between a DataSet object and the source data storage. It extracts data from physical storage and pushes it to data tables and relationships. The DataSetCommand object is also responsible for transmitting any update, insert, or delete operations to the actual database. The DataSetCommand object performs this function through SQL commands or command strings that the underlying OLE DB provider can understand. DataSetCommand objects exist in two forms:

SQLDataSetCommand object

ADODataSetCommand object
They can be used as proxies between data tables and corresponding tables in the data source. The data source is SQL Server 7.0 (or an updated version) used for the SQLDataSetCommand object and any other OLE DB Provider USED FOR THE ADODataSetCommand object.

Generally, ADO + can identify and process two types of data sources: SQL Server 7.0 (and later versions) and any data sources that can be accessed through the OLE DB Provider. These are also known as managed providers.

As a replacement for DataSetCommand objects (as shown in sample code 1), you can use familiar objects such as connections and commands, directly operate on the managed provider.

Sample Code 1

Dim oDS as DataSet
Dim oCMD as SQLDataSetCommand

ODS = New DataSet
OCMD = new SQLDataSetCommand ("Select * from employees", strConn)
OCMD. FillDataSet (oDS, "EmployeesList ")

Dim oRow as DataRow
For Each oRow in oDS. Tables (0). Rows
Console. WriteLine (oRow (0). ToString ())
Next

By viewing this type of ADO + code, you will find that it is not much different from the old-style ADO programming. It has new objects, new programming interfaces, and improved new functions, but the code pattern is the same. As shown in code example 2.

Sample Code 2

Dim oCN As SQLConnection
Dim oCMD As SQLCommand
Dim oDR As ADODataReader
OCN = New SQLConnection (strNWind)
OCMD = New SQLCommand ("MyStoredProc Davolio", oCN)
OCMD. CommandType = CommandType. StoredProcedure
Try
OCN. Open ()
OCMD. Execute (oDR)

While oDR. Read
Console. WriteLine (oDR ("LastName"). ToString ))
End While
Catch e As Exception
Console. WriteLine (e. ToString)
Finally
ODR. Close ()
OCN. Close ()
End Try

Note that the above Code has Microsoft Visual Basic®7.0 the features of some syntax elements introduced-especially the Try-Catch structure that eventually replaces the On Error mechanism. ADO + Code fully utilizes. NET runtime services that provide system objects such as the Console.

What other special functions can help you determine whether the innovative DataSetCommand method is better than the usage?