Although the ADO(dot)NET library has a not too complicated architecture, it contains many classes. Each class has many ways of instantiating using each other’s objects. This makes many newcomers to ADO.NET feel confused and confused. Actually, if you understand the architecture of the ADO.NET library, everything will be much simpler and easier to understand.

This lesson will show you in detail the ADO.NET architecture, the main components of the ADO.NET library, the data sources that ADO.NET can access, the concepts and data providers for ADO.NET Architecture.

By the end of the lesson you’ll have a systematic look at ADO.NET and its key classes, as well as how the classes relate to each other. This will be of great help as you dive into each specific component of ADO.NET.

Role and Position of ADO.NET Architecture

A program’s data is the most important component and can be stored (and retrieved) in a variety of ways. There are two main directions: (1) self-managing data; (2) use a specialized program or architecture to manage data, commonly referred to as a database. Word or Notepad use the first trend, while specialized management applications (Line-of-Business, LOB) often choose the second direction.

For the direction of using the database, there are also two options: (1) using a database in client-server architecture, (2) using a file-based database. Excel is an application that uses option 2. While option 1 is common in LOB applications. They are also collectively referred to as data sources.

Databases store information in their own form. The most common is tabular, but can also be XML or Json. Meanwhile, the program stores information in the form of a hierarchical chain of objects.

As such, there is a big difference between the way databases process information and programming languages. This is where ADO.NET plays its role: the middleman between the database and the program.

ADO.NET is part of the .NET framework. It serves as a toolkit and an intermediary layer that helps the program interact with the data source.

Architecture of ADO.NET In General

The ADO.NET architecture can be divided into two components: the connected component and the local component (disconnected). This division is related to the roles and responsibilities of objects in ADO.NET. These two components interact with each other through a special component: the Data Adapter.

Connected Components

The connected component includes objects responsible for directly interacting with the data source: connection, command, parameter.

Notice, here we are only talking about objects and not specific classes because ADO.NET can work with many types of data sources. For each type of data source will have to use a separate class group. However, these classes must all implement a common interface.

Connection is responsible for connecting to the data source. The main jobs the connection takes on is to open / close the connection, check the connection status. All the rest of the Connected group members operate on connection.

Command is the component responsible for executing queries such as read, write, update, delete data (collectively called CRUD – Create – Retrieve – Update – Delete command group). Command can also be responsible for working with the structure of the data source, for example changing the table structure. Commands operate on a specific connection.

Parameter is responsible for dynamically and securely passing parameters to queries. Parameter works on Commands and helps to pass parameters to Commands.

This component depends on the type of data source. For example, to work with SQL server must create a dedicated object for this data source type (from the SqlConnection class); For Oracle, the object will be created from the OracleConnection class.

Disconnected Component

This component is responsible for creating a copy of (part of) the database in program memory. This copy allows the program to work with the data without maintaining a constant connection to the data source.

To create a “copy” of the database, the Disconnected component contains classes that simulate the structure of the database, including:

• DataSet (simulate the whole database),
• DataTable (simulate data table),
• DataRow (data stream),
• DataColumn (column of data),
• DataView (similar to Sql Server view),
• DataRelation (relationship between tables).

The disconnected component does not depend on a particular data source. Data from any data source can be dumped into DataSet, DataTable.

The Disconnected component cannot work directly with the data source on its own. Instead, it must interact with the connected component through the Data Adapter to perform CRUD operations.

Data Adapter

The Data Adapter is a special intermediary that helps the Disconnected component work with the Connected component. The Data Adapter supports automatically performing CRUD operations with the data source as needed.

The Data Adapter can be visualized as a bridge between the local data (of the Disconnected component) and the Connected component. For example, when the Disconnected component needs data, the Data Adapter automatically calls the Connected unit to connect and query the data. When Disconnected needs to save data back, the Data Adapter calls Connected to execute the corresponding query.

As on the ADO.NET architecture diagram we can notice, although looking at the overall program that interacts with ADO.NET. However, we have a few specific options:

• (1) only works with Connected components;
• (2) only works with Disconnected component;
• (3) combination.

Data Provider

ADO.NET divides the Connected component by type of data source. For example, to work with SQL Server will need a separate class group (located in the System.Data.SqlClient namespace). Similarly, to work Oracle also needs such a group of classes (in the System.Data.OracleClient namespace). A group of classes for the Connected component to work with such a specific type of data source is called a Data Provider.

To work with each type of data source will have to build and use a corresponding data provider. The data provider model makes ADO.NET more flexible and flexible when it comes to accessing new types of data sources. Any database developer can create their own data provider for ADO.NET to support their database.

In the framework of this course we only work with providers for SQL Server. Once you know how to work with a provider, you can completely learn to work with other types of providers yourself.

Providers like SqlClient or OracleClient are called specialized providers. Whereas ODBC or OleDb are known as generic providers. Dedicated Providers have high performance and exploit the unique features of the data source. Generic Providers are limited in performance but allow working with many different types of data sources.

Conclusion

In this lesson we looked at the role and place of ADO.NET in .NET framework application development. We also looked at the basic architecture of ADO.NET in detail.

Here we determine to focus deeply on the Connected component of ADO.NET as it will continue to be used in Entity Framework. The Disconnected component is outdated and is no longer recommended. We will not go into depth about this component. Instead we will turn to the content about Entity Framework.

The content of the following articles will in turn go into the details of each part of this architecture.

If you feel the site useful, before you leave please help the site with a small action so that it can grow and serve you better. 

If you find this article useful, please help share it with everyone. 

If you have any concerns or need to comment further, please write in the discussion section at the bottom of the page. Thank you for reading.