ADO.NET is part of Microsoft.NET which comprises a set of tools and object model for accessing a data source. The objects definition appears under the System.Data namespace. It allows applications to store, manipulate and retrieve data. In this article I'm going to talk about the two different objects model for accessing data sources in two different contexts of your application: the connected and disconnected environment.

In the connected environment, the objects insist on having an open connection with the database management system for interaction with the data source. It's represented by instances of the following classes Connection, Transaction, Command, Parameter and DataReader.

A DataReader instance allows to access information on a single row of data at a given time having a single record loaded in memory, regardless of the size of a result set. The performance advantages associated with using less memory can be enormous. 

If you keep a data reader open for unduly long time durations, then the connected nature of a data reader can actually impact connection-pooling performance negatively.

If you are working on the one row and explicitly not close the data reader and the connection, your physical connection is still open and cannot be used by anyone else for reading other row. This problem may impact in the performance and availability of the database management system

The disconnected environment.

In the disconnected environment, the application keeps open the connection for one kind of work on the database and every time it needs to work again, the connection must be reopened. It's costly to open a connection in a network environment due to the communication protocols, the session creation and the underlying authentication process. Microsoft architects mitigate this effect storing the actual physical connection between various requests in a connection pool, so every time a new connection object is created associated to connection string pointing to the database management system, and needs to open the connection, the connection string is used as key for looking a physical connection in the connection pool whose structure is hash table, and accessing to a reference of the underlying opened physical connection. It is a great idea, and time saving algorithm.

The disconnected environment comprises instances of the following classes DataSet, DataTable, DataRow, DataColumn, DataRelation and Constraint which allows abstracting a real object-oriented model of the back-end database.

DateSet is designed specifically to be an in-memory cache of large amounts of data completely disconnected from the underlying data source. In this regard, the DataSet consumes more memory than the DataReader.

As DataSet is database independent, so we need another intermediary object called Adapter which contains the necessary logic for accessing the underlying data source. First of all, the adapter fills the DataSet with a snapshot of the real data source, and later updates the changes back, so you will still need to reconnect to the data source, because the connection was closed while you were actually working with the data in your application.

Strongly type DataSet.

Strongly typed DataSet is a kind of DataSet trying to come close to the true representation of your data. The main idea is to define objects closer to the real model of your application than the underlying database structure. 

When we design the architecture of an Enterprise Application using object-oriented concepts, we deal with classes and its relationships and the associated instances: the objects. These models are implemented using tools and technologies supporting the object-oriented paradigm in a coherent way. 

Dealing with persistent objects and relational database systems have been a challenge for the architects and programmer community, one solution is XML and related technologies for structuring the raw information in a object-oriented approach. Some vendors are developed frameworks to allow the objects to be persistent such as ObjectMagix framework and Kodo EJB/JDO from BEA Systems. 

The entities, part of your business domain, are modeled as Business Objects, that is persistent objects acting as an information holders which are able to persist their state on any storage medium. For example, if you are modeling the architecture of Customer-Relationship Management information system for the marketing department, you must deal with entities such as Products, Customers, CustomerProfiles, etc.  

The programmers assigned to the realization of the business layer, according to the design-pattern practices of n-tier enterprise applications, developing different components now agree in a common vocabulary as interface for exchanging messages with the objects in other layers such as the User Interface layers. In the integration phase of the project, we deal with Products, Customers and CustomerProfiles components its related interface inside a package and hosted by a certain runtime environment; not with an unstructured stream of data and related data-dependent commands. 

A component-based model allows testing, maintaining and reusing the software modules in a logical an easy way. 

Some programmers have good designs, runtime environments and IDE, but they don't use at full this technologies and concepts, because they are not able to realize the underlying model, turning into a major headache the solution. 

Using strongly typed DataSet and related concepts such as XML and XML Schemas for describing the objects schemas (classes attributes), we may model business objects and its relationships in ADO.NET. The logic of the application is consistent with the model, that is, when we write a piece of code to create an object, the associated record for storing the object's state will be created in the database.

We can also check any error, inconsistency or constraints set by the business rules before the data goes to the database systems. Now we are really dealing with entities independent of the persistent medium. 

The biggest problem with strongly typed DataSets is that their structure needs to be continually updated to reflect the underlying table structure. This involves code generation and recompilation. 

I want you to say, this is an interested topic, and there are a great deal of paradigms, concepts (persistent objects) and technologies (EJB, Kodo EJB/JDO, ObjectMagix) referring to it. This article is only a notion of the basis of object's persistence.

NOTE: THIS ARTICLE IS CONVERTED FROM C# TO VB.NET USING A CONVERSION TOOL. ORIGINAL ARTICLE CAN BE FOUND ON C# CORNER (WWW.C-SHARPCORNER.COM).