With nearly any application, a data source is likely to be the root foundation of all functionality. Without being able to store data your application obviously won’t be able to do a whole lot. The database, or data source, and your application’s code base cohesively comprise what we call an application; neither the code nor the data source would be of much use without the other.
Being such a fundamental component of an application, methodologies for working with data sources has evolved greatly over the years. If you recall classic ASP there was very little structure or design behind the database connections and data manipulation patterns
With classic ASP you needed to use ADO, which were COM classes you could instantiate nearly anywhere on any ASP page and could read/write data in any arbitrary location on the script. Although the classes were well defined and quite handy to work with, they left developers to their own devices when trying to design database patterns.
Unless you had your database logic in an ActiveX DLL you also didn’t have access to the helpful code-insight shortcuts which would make development much easier since you could clearly see the methods and properties available to you. If you scripted your database logic in ASP pages it was usually a matter of trial and error, changing code and refreshing the page to test over and over.
The next generation of ADO has been labelled ADO.NET since its creation coincided with the release of the .NET framework. ADO.NET is now a managed set of clearly organized classes which can connect to nearly any data source you can think of.
No longer is your database code embedded into your front end pages; now you can define entire dedicated components to house your database logic and access them in an Object Oriented fashion. Additionally, the data wizards for the Data category of ASPX controls are capable of writing the data connectivity code for you, so developers that are not familiar with ADO.NET can still write database connected applications.
One of the troubles with these wizards however is that you really don’t have a grasp of what’s happening in the code-behind files to make your database connectivity happen. If you encounter a bug it’s difficult to track down because you didn’t write the code yourself.
The purpose of this tutorial is to look at some of the basic principles behind ADO.NET and its classes, as well as look at some common methods and properties used to access data.
Note: ADO.NET can be utilized in any type of Visual Studio .NET project. For this tutorial we will assume ASP.NET is the project type. Visual Studio .NET is not required but recommended if you want to test out some sample code, and installation of the MSDN library is required to follow the links provided in the tutorial