ADO.NET disconnected classes are basic building blocks of the ADO .NET architecture. The classes are independent of data providers and data source. In other words, you can use these classes with data providers as well as without data providers.
ADO .NET data providers are sets of classes designed to work with multiple data source to provide the best out of all the database access technologies. ADO.NET provides many data providers to work with different kinds of data sources, including OleDb, ODBC, and Sql. As you can guess from their names the OleDb data providers work with OLEDB data sources, ODBC data providers work with ODBC data sources, and Sql data providers work with SQL server 7 or later databases.
Although ADO.NET is a new programming model, it uses some of the old data access technologies to access different data source. For example, the OleDb data provider uses the native OLE DB application programming Interface (API) to access OLE DB data sources. Similar to OLE DB data sources, the ODBC data provider uses ODBC drivers and ODBC Admin to access ODBC data source. ADO.NET data providers wrap up these technology and provide a high-level programming model to make it easier to program.
So what's new? That is a good question. Weren't you using the ODBC and OLE DB APIs in previous data access technologies? You're right. ADO.NET still uses the same native API. The only difference is that ADO.NET provides high level, object-oriented classes that are easy to program and understand. Further, all the data providers supply the same programming model. So if you know how to write applications using OleDb data providers, you'll be able to write application using ODBC or Sql providers in no time. It's just a matter of changing the class names and connection strings. To leave OleDb and ODBC data providers behind, Sql data providers supply much improvement in comparison to using ODBC. Sql data providers directly connect to the lower-level layer in the infrastructure that by passes ODBC admin and ODBC drivers.
Looking at the ADO. NET Architecture
You briefly looked at the ADO.NET architecture in earlier article. Now you'll see a broad view if the ADO.NET architecture and learn how disconnected and connected components (classes) provide access to multiple data source. In this section, I'll talk about objects in general. The following sections of the article will discuss the ADO.NET components based on data providers.
Figure below shows the basic architecture of the ADO.NET model. As you can see the entire ADO.NET model sits between the data source and client application that can be built using Windows Forms, Web Forms, or even console based application. The Connection is the first component that talks to a data source. In ADO.NET each data provider (OleDb, Sql Odbc, or Oracle) has its own Connection class. The Connection component is a mediator between a DataAdapter (or a Command) component and data source. The DataAdapter components create SQL INSERT, SELECT, UPDATE, and DELETE statements that add, read, update, and delete data from a data source respectively. Not only does a DataAdapter create these SQL statements, it also executes these statements. Basically, a DataAdapter (with the help of Command) physically updates and reads data from a data source. In figure, an arrow shows this flow of data.
You can use the Command components with or with out a DataAdapter. You can directly Executes SQL statements using the Command object's methods. You can also read data in DataReader object using the Command object, which provides a read only forward–only fast access to data. This is best when you need to read data in only applications that are not data-bound. You can also see from figure that all arrows are double-sided arrows except the arrow connecting a DataReader and Command. A double-sided arrows except the arrow connecting a DataReader and Command. A double -sided arrows means data transfer is possible in both sides. A DataReader can only read data, which is why DataReader has only a one-sided arrow. This shows that you can fill a data reader from the command, but you can't send back data from a data reader to the command.
A DataAdapter sits between a data source and a DataSet, It provides Fill and Update methods to fill a dataset from a data source based on the SELECT statement, and the Update method saves a dataset's change to the data source. The DataSet plays a vital role in data-bound Graphical User Interface (GUI) applications to display and manipulate data. Not only does it provide fast data manipulation using XML schemas, it also provides multiple views of data that can be bound with multiple windows Forms and Web Forms data-bound controls.
Figure: ADO.NET architecture
A DataSet is a collection of DataTable components. A DataTable represents a table in a data source. You can apply a filter or do sorts on a table. You can bind a DataTable to data-bound controls such as a DataGrid, DataList, Listbox, or ComboBox using a DataView. You can also apply sorts and filters on a DataView. As you can see from figure, there are three datasets represented as three DataTables. Each DataTable binds too different data-bound controls using different DataViews.
Note: As you can see, some arrows are single-sided and some are double-sided. For example, you can see from the figure that you can use a data reader only to read data from a command object, but you can use a dataset to read and write both. I'll use the same style throughout the article.
Conclusion
This was an overview of the ADO.NET architecture. I'll discuss these controls in more detail in my coming articles. See my other articles on the website on ADO.NET.