Chapter 3: ADO.NET in Disconnected Environments

Overview

In Chapter 1 and Chapter 2, you learned about ADO.NET, and you learned how to use ADO.NET components with Visual Studio (VS) .NET. You also learned how to write code that binds ADO.NET components to data-bound controls and how to use VS .NET's Integrated Development Environment (IDE) wizards to write full-fledged database applications.

In this chapter, you'll get a broad view of the ADO.NET architecture and the basic building blocks of ADO.NET in a disconnected environment. Now, the first question on your mind might be, "What is a disconnected environment?" Generally, when we talk about ADO.NET and data access, we're talking about data stored in a database server such as a SQL Server or Oracle. Actually, ADO.NET not only provides a way to work with databases, it also allows you to access various kinds of data sources and even in-memory representations of data. In-memory data is stored in a system's memory and erased when an application is closed. Data that is held in-memory is referred to as a disconnected environment.

Why use in-memory data? Well, there may be occasions when you don't want to store data in a database but you want to perform some actions such as adding, deleting, sorting, and searching data, and once you're done, you don't care what happens to the data. This scenario would be perfect for working with disconnected data.

Note

In Chapter 4, we will concentrate on working with connected data, where data will be stored in a database. In the connected environment, you use a data provider to connect to a database and read and write data using the data provider classes.

ADO.NET disconnected classes are basic building blocks of the ADO.NET architecture. The classes are independent of data providers and data sources. 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 sources to provide the best 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.

Note

You can access SQL Server 6.5 or previous versions using ODBC or OleDb data providers.

Although ADO.NET is a new programming model, it still uses old native data access technologies to access different data sources. For example, OleDb data providers use the native OLE DB Application Programming Interface (API) to access OLE DB data sources. Similar to OLE DB data sources, ODBC data providers use ODBC drivers and the ODBC Administration to access ODBC data sources. ADO.NET data providers wrap up these technologies for easier programming.

So, what's new in ADO.NET? 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 uses the same native API. The only difference is, 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 applications using ODBC or Sql providers in no time. It's just a matter of changing the class names and connection strings. When working with SQL Server databases, the Sql data provider is much more efficient and faster in comparison to the OleDb or ODBC data providers. Unlike ODBC and OleDb data providers, which use ODBC and OLE DB data layers to connect to a SQL Server database, the Sql data provider uses the native SQL Server layer to connect to the databases. We discuss this in more detail in later chapters.