ADO.NET is the .NET technology for interacting with data sources. You have several Data Providers, which allow communication with different data sources, depending on the protocols they use or what the data base is. Regardless, of which Data Provider used, you'll use a similar set of objects to interact with a data source. The SqlConnection object lets you manage a connection to a data source. SqlCommand objects allow you to talk to a data source and send commands to it. To have fast forward-only read access to data, use the SqlDataReader. If you want to work with disconnected data, use a DataSet and implement reading and writing to/from the data source with a SqlDataAdapter.
This is just the beginning - the first of several lessons in the ADO.NET Tutorial. The next one in this series is Lesson 02: The SqlConnection Object.The SqlConnection Object:
This lesson describes the SqlConnection object and how to connect to a data base. Here are the objectives of this lesson:- Know what connection objects are used for.
- Learn how to instantiate a SqlConnection object.
- Understand how the SqlConnection object is used in
applications.
- Comprehend the importance of effective connection
lifetime management.
Introduction
The first thing you will need to do when interacting with a data base is to create a connection. The connection tells the rest of the ADO.NET code which data base it is talking to. It manages all of the low level logic associated with the specific data base protocols. This makes it easy for you because the most work you will have to do in code is instantiate the connection object, open the connection, and then close the connection when you are done. Because of the way that otherclasses in ADO.NET are built, sometimes you don't even have to do that much work.Although working with connections is very easy in ADO.NET, you need to understand connections in order to make the right decisions when coding your data access routines. Understand that a connection is a valuable resource. Sure, if you have a stand-alone client application that works on a single data base one one machine, you probably don't care about this. However, think about an enterprise application where hundreds of users throughout a company are accessing the same data base. Each connection represents overhead and there can only be a finite amount of them. To look at a more extreme case, consider a Web site that is being hit with hundreds of thousands of hits a day. Applications that grab connections and don't let them go can have seriously negative impacts on performance and scalability.
