Evolution of ado+-guided data types (transfer from MS II)

What does the ado+ add?



In the most abstract terms, ado+ is ADO with greater scalability and interoperability. As far as object model and programming problems are concerned, ADO and ado+ are completely different two entities. Despite this, ado+ originated from ADO and retained its inspiring principles.



The key to enriching ADO with more interoperability and scalability is to disconnect the concept. While allowing client-side scripting code to implement interesting and interactive features such as sorting, filtering, and document/view models, disconnected recordsets are introduced into ADO 2.0 as a way to retain system resources. Ado+ has three main benefits compared to ADO: interoperability, enhanced scalability, and strong typing. In addition, ado+ facilitates data sharing between data components and navigation between records in a table.



Ado+ was designed to operate on disconnected datasets from the outset. Disconnected recordsets can only benefit applications because they are a local view of the data that can be processed and transferred faster. Ado+ uses XML as a common transport format. As long as the receiving component runs on a platform that is available to the XML Analyzer, it can provide many features while ensuring interoperability. When transferring through XML, the receiver no longer has to be a COM object. XML is a simple but powerful text-based standard that has recently become widely accepted by the industry, so there is reason to expect an XML analyzer on almost every platform. In this way, the receiving component will not have any architectural limitations. Any pair of software components can share ado+ data, as long as they agree to use the same XML schema for the transfer data format. Figure 2 illustrates how ado+ applies to the existing architecture.





Figure 2. Use of ado+ in DNA solutions



The presentation layer can use or create a dataset by using either Win forms or Web forms, which are dedicated to the Microsoft Visual Studio.NET platform. In either case, the component running at the business level receives an XML stream and handles it arbitrarily. These components can reconstruct a ado+ environment, or you can process the data in raw XML and make it suitable for sending to the physical data store. A business component can get ado+ data, convert it to XML, and then send it back to the client. Any application that understands XML can get involved in this architecture at any point.



Scalability is the ability of a distributed system to service a growing number of clients without losing efficiency. Scalability is an often database-related term, because distributed systems rely heavily on databases. Scalability is a persistent problem for both the database server and any software artifacts that encapsulate data access operations. The biggest enemy of scalability is the misuse of critical resources. In a distributed system, the key usually means limited. A database connection is an example of a critical resource that can affect scalability. The availability of a fixed number of connections creates a real limit to the growth and capabilities of the system. Good Software understands the situation and takes appropriate measures to limit its impact. Ado+ How to deal with this problem is superior to ADO? Instead of saying that ADO is not scalable, it says that the intrinsic use of disconnected and in-memory tables (which is the ado+ feature) makes ado+ an inherently more scalable solution. It is more scalable because disconnected datasets do not retain locks or remain open for long periods of time. If you use ADO, you must write code to get this functionality, and using ado+ will get it for free.



The transport language that uses XML as a dataset can be more efficient than ADO for data sharing. First, COM collections that are necessary to bypass COM objects such as recordsets enable components to use a collection of any data types that they want to use. This also leads to better performance because there is no longer a need to ensure that data type conversions are recorded for standard COM data types. The use of XML and HTTP also allows data to be skipped over firewalls. Normally, the firewall allows HTTP packets to pass, but it blocks any other content that attempts to enter through a port that is not 80.





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





The constituent elements of ado+



Now I want to introduce the main ado+ object. We begin with the origin of all content, the DataSet object.



Data set is the evolution of ADO recordset. The dataset is nothing more than a disconnected, in-memory view of the database. There is no strict relationship between a dataset and a data source in terms of any information that you can have dynamically created datasets and datasheets without needing to come from a database management system (DBMS). In other words, the dataset uses some of the features added to the ADO Recordset: the ability to work when disconnected, and the planned creation and placement of any kind of data. A dataset can contain any number of tables, and each table usually (but not always) corresponds to a database table or view. A table for a DataTable object is just a collection of rows and columns. Each row retains its original state and its current state.



An ADO recordset always appears as a generic data type that acts as a super array. Similarly, a ado+ dataset is a super Recordset that provides the following features:



A better and richer programming interface for accommodating data.





An object model that does not require any intrinsic binding to the actual data source to provide a more generalized view of the data.





An xml-based standard console for input and output.

An ADO recordset is basically a (possibly hierarchical) collection of records with specific methods for accomplishing some interesting functions. These include scrolling, sorting, filtering, and bookmarks. The recordset is essentially a copy of the table in memory. The dataset, which looks more like a SQL Server or Access database, is an entity that contains more tables, specific views, and foreign key relationships.



The DataSet object model reflects this larger scope, which allows you to view available data across multiple sets of data tables, relationships, extended properties, and rows-which can also be used to illustrate non-persistent data or just another persistent storage medium that is not a database.



The ADO recordset allows you to save content to XML and reconstruct the content from an external XML file. However, the default XML schema used is optimized for exporting/importing ADO recordsets, not for actual data exchange. The ADO XML schema contains a number of information about column types and locations, as well as other meta data. This information is critical if you want to rebuild the recordset from an XML document, but it is not useful if you just want to pass the data and have the recipient use it. With the ado+ dataset, the XML schema is more concise because the objects represented are not directly related to the relational database, although objects can be used to accurately reproduce the database. The ado+ dataset describes the data, and the ADO Recordset describes a collection of records obtained from a table. This is where the ado+ data model is moving.



ado+ XML schemas simply reproduce the relationships defined in tables and datasets, and the responsibility for building a DataSet object is left to the ado+ runtime. ADO XML format is too specific to truly interoperate. It is also because it is too cumbersome, without the data compression of human intervention, it can not be efficient collection. There is a low-level similarity between the inspiring principles of the ado+ DataSet architecture and the reason why I created JavaScript's Recordset objects. In both cases, you convert the data description (for example, an XML string) to a platform-specific action object (that is, a JavaScript object). In doing so, you safely send your data from one level to another, regardless of the installed operating system or software.





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





ado+ command



Although the DataSet object provides a tool for data storage in memory, you need another tool to create and initialize various tables. This tool is the DataSetCommand object, which represents a centralized console that hides the details of connections and commands. The DataSetCommand object allows data retrieval and preservation between a DataSet object and the source data memory. It is responsible for extracting data from physical storage and pushing it into the data tables and relationships. The DataSetCommand object is also responsible for transferring any update, insert, or delete operations to the actual database. The DataSetCommand object accomplishes this by using an SQL command or command string that the underlying OLE DB provider can understand. The DataSetCommand object exists in two ways:



Sqldatasetcommand objects





Adodatasetcommand objects

They can be treated as proxies between corresponding tables in a datasheet and in a data source. The data source is SQL Server 7.0 (or later) for the Sqldatasetcommand object and any other OLE DB provider for the Adodatasetcommand object.



In general, ado+ can identify and process two types of data sources: SQL Server 7.0 (and later), and any data sources that can be accessed through OLE DB providers. These are also referred to as managed providers.



As an alternative to using the DataSetCommand object (as shown in code Example 1), you can manipulate the managed provider directly by using more familiar objects such as joins and commands.



code Example 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 looking at this type of ado+ code, you'll find that it's not much different from legacy ADO programming. It has new objects, new programming interfaces, new, improved functionality, but the code pattern is the same. As shown in code example 2.



code Example 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 the characteristics of some syntactic elements introduced by Microsoft Visual basic®7.0-especially the try-catch structure that eventually replaces the on Error mechanism. The ado+ code leverages the. NET Run-time services that provide system objects such as Console.



Are there any special features that can help you determine if the innovative datasetcommand approach is better than using traditional ADO? Communicating with a data source by using a DataSetCommand object is essentially the same as using ADO connections and commands, with an important corollary: all ado+ objects, such as DataSetCommand objects, can be customized by deriving new, more specialized classes. So, for example, you can control how data set changes are delivered to the database, and (for example) optimize performance, compress or encrypt data, perform data validation, and many other functions.





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





Strongly typed programming



You manipulate database objects and collections of similar recordsets and Fields through ADO. There is nothing wrong with this method except to treat the actual data as some kind of parameter:



Set ORS = New ADODB. Recordset

oRS.Open strSQL, strconn

While not ors.eof

MsgBox ORS ("FirstName") & "" & ORS ("LastName")

Ors.movenext

Wend



In the above ADO code snippet, the first and last names are used as entry points into the Recordset and Fields collection. Because of the default properties of Visual Basic, you can write code that is relatively easy to read. According to ADO, the full object model path for a given record field should be:



Ors.fields ("FirstName"). Value



In addition, ADO always uses a Variant data type to conform to the scripting environment, especially the ASP.



Ado+ makes database programming a step further by providing the ability to access data stored in a dataset with the natural name of the data. If you are addressing a table in a dataset, you can use the ado+ name of the table and access columns and rows with the names of columns and rows, rather than through a collection based method. In addition, all the relevant variables have a specific (and Variant-relative) data type. This is called strongly typed programming. The code shown above to manipulate the FirstName and LastName in a Employees table can be rewritten in the following form:



MsgBox Employees.firstname & "" & Employees.lastname



A dataset that has a type is a class that inherits from the DataSet. It is useful to take a strongly typed version of a dataset because the IDE itself can notify you in real time of possible type mismatch errors, and Microsoft intellisense® technology can recommend methods and properties to you at any time.





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





Summary



Ado+ is not just another object model that operates on data. Essentially, it is the reappearance of ADO in a broader, cross-platform scenario. Ado+ is an extended ADO that works with any software component on any platform that can understand XML. It models the data, not the database or the data provider. It extracts data from the database infrastructure and places it in a neutral environment in which data is data, regardless of storage media, physical structure, or what the API is used to access it. The key is XML, which represents an I/O console for ado+ datasets. Another important aspect is the disconnect of the primary object (that is, the dataset) and the nature of the memory.



Therefore, you can send the XML description of the data and have the ado+ server-side components build it into a dataset. You can also have ado+ components that simply get the XML description and run their own analyzer and get the same results. Ado+ is dedicated to Windows, but it can exchange data with almost any platform. Please note follow-up articles that track ado+ evolution.