ADO.NET is a set of classes in Visual Basic .NET that allows for data access. This tip, excerpted from InformIT, defines ADO.NET and discusses how you can use it.
Dan Fox is the author of Building Distributed Applications with Visual Basic.NET, from which this article comes.
ADO.NET is comprised of classes found in the System.Data namespace that encapsulate data access for distributed applications. However, rather than simply mapping the existing ADO object model to .NET to provide a managed interface to OLE DB and SQL Server, ADO.NET changes the way data is stored and marshaled within and between applications. The primary reason ADO.NET redefines this architecture is that most applications developed today can benefit from the scalability and flexibility of being able to distribute data across the Internet in a disconnected fashion.
Because the classic ADO model was developed primarily with continuously connected access in mind, creating distributed applications with it is somewhat limiting. A typical example is the need to move data through a Recordset object between tiers in a distributed application. To accomplish this in classic ADO you have to specifically create a disconnected Recordset using a combination of properties including cursor location, cursor type, and lock type. In addition, because the Recordset is represented in a proprietary binary format, you have to rely on COM marshalling code built into OLE DB to allow the Recordset to be passed by value (ByVal) to another component or client code. This architecture also runs into problems when attempting to pass recordsets through firewalls because these system level requests are often denied.
On the other hand, if you elected not to use disconnected recordsets, you had to devise your own scheme to represent the data using Variant arrays, delimited within a string, or saved as tabular XML using the Save method (although the latter option is really only viable when using ADO 2.5 and higher). Obviously these approaches have their downside because they run into problems with performance and maintainability not to mention interoperability between platforms.
In addition, the classic ADO model doesn't handle hierarchical data particularly well. Although it is possible to create hierarchical recordsets using the Microsoft data shape provider, it is not simple and is therefore not often used. Typically JOIN clauses are used inside stored procedures or inline SQL to retrieve data from multiple tables. However, this does not allow you to assemble data from multiple data sources and easily determine from where the data comes. As a result, classic ADO provides a flat view of data that is not strongly typed.
To alleviate these problems, ADO.NET is built from the ground up for distributed applications used in today's disconnected scenarios. For example, the central class in ADO.NET is the DataSet, which can be thought of as an in-memory XML database that stores related tables, relationships, and constraints. As you'll see, the DataSet is the primary mechanism used in VB.NET applications to cache data and pass it between tiers in a distributed application thereby alleviating the need to rely on proprietary schemes or COM marshalling.
Using XML alleviates several of the burdens of classic ADO. For example, by storing the data as XML it can easily pass through firewalls without special configuration. In addition, by storing related tables and representing the relationships between those tables the DataSet can store data hierarchically allowing for the easy manipulation of parent/child relationships. The self-describing nature of XML combined with the object-oriented nature of VB.NET also allows for direct programmatic access to the data in a DataSet in a strongly typed fashion. In other words, the data need not be accessed using a tables, rows, and columns metaphor but can be accessed in terms of the definition of the data that can be type checked by the compiler.
Furthermore, this disconnected model combined with connection pooling schemes frees resources on the database server more quickly, allowing applications to scale by not holding on to expensive database connections and locks.
To read the entire article from which this tip comes, click over to InformIT. You have to register there, but the registration is free.
To learn more about Building Distributed Applications with Visual Basic.NET, or to buy the book, click here.
