Theory
FestConnect needs a database
So far FestConnect's events and registrations have been hand-waved as 'a list'. In reality they live in a database, the kind you learned to design and query with SQL in DBMS. The question now is: how does a .NET web application actually talk to that database, to read the events and save a registration?
The answer is ADO.NET, the part of the .NET Framework built for exactly this. This lesson introduces what ADO.NET is and the one big choice it offers you: connected or disconnected.
Theory
What ADO.NET is
ADO.NET is the data-access component of the .NET Framework: a set of classes your application uses to connect to a database, run SQL commands, and handle the results. It is not a database itself; it is the bridge between your C# code and whatever database you use (SQL Server, and others through providers).
Think of it as the plumbing between FestConnect and its data. You give ADO.NET a connection and a SQL command; it carries your query to the database and brings the rows back. How you handle those rows is where the two models differ.
Formula
Connected vs disconnected: the core idea
ADO.NET offers two ways to work with data.
Connected: you open a connection, read the rows while it stays open (using a DataReader), then close it. Fast and light, but you must hold the line open the whole time you read.
Disconnected: you open the connection just long enough to copy the data into memory (a DataSet), then close it and work with the in-memory copy freely. You hold the connection only briefly.
One streams over an open line; the other grabs a copy and hangs up.
Theory
When each fits
The connected model (a DataReader) is ideal when you just want to read rows quickly and move on, for example, listing FestConnect's events straight onto a page. It is forward-only and read-only: you stream through the rows once, top to bottom. Minimal memory, maximum speed.
The disconnected model (a DataAdapter filling a DataSet) is ideal when you want to hold data in memory, page through it, bind it to several controls, or edit it and push changes back later, all without keeping the database connection tied up. You trade a little memory and setup for freedom from the open connection.
Quiz
What is the key difference between ADO.NET's connected and disconnected models?
- Connected uses SQL, while disconnected does not use SQL at all
- Connected keeps the database connection open while you read rows; disconnected copies data into memory and closes the connection, so you work with the copy
- Disconnected works without a database, while connected needs one
- They are two names for the same thing
Show the answer
Connected keeps the database connection open while you read rows; disconnected copies data into memory and closes the connection, so you work with the copy
The distinction is about the CONNECTION. In the connected model you keep the connection open and read rows through it (a DataReader), streaming forward. In the disconnected model you open the connection only long enough to copy data into memory (a DataSet via a DataAdapter), then close it and work with the in-memory copy. Option A is wrong: both use SQL to fetch data. Option C is wrong: both need a database; 'disconnected' means the connection is closed AFTER loading, not that there is no database. Option D is wrong: they are genuinely different approaches with different trade-offs (speed and low memory vs flexibility off the open line).
Think first
Why would you ever disconnect instead of staying connected?
If the connected reader is faster and lighter, why does the disconnected DataSet model exist at all? Then tap.
Show the answer
Because a database connection is a SCARCE, SHARED resource, and holding it open is costly at scale. A web server like FestConnect may serve hundreds of users at once, and databases allow only so many simultaneous connections. If every page kept its connection open the whole time it displayed, paged, and edited data, the server would run out of connections fast. The disconnected model grabs the data quickly, releases the connection immediately, and then lets you work with the in-memory copy for as long as you like, so the precious connection is free for the next request almost at once. It also lets you bind the same data to several controls, sort and page it, and edit it offline before saving. The connected DataReader is perfect for a quick read-and-render; the disconnected DataSet is better when you need to keep and manipulate the data while being kind to the connection pool. Grab, release, work with the copy: that is the disconnected philosophy.
At a glance
| Aspect | Connected (DataReader) | Disconnected (DataSet) |
|---|---|---|
| Connection | Stays open while reading | Opened briefly, then closed |
| Data | Streamed, forward-only, read-only | Copied into memory, editable |
| Speed and memory | Fast, very light | More memory and setup |
| Best for | Quick reads onto a page | Holding, paging, editing data offline |
Summary
Key takeaways
- ADO.NET is the data-access component of the .NET Framework: the classes a .NET app uses to talk to a database.
- It is a bridge, not a database: you supply a connection and SQL, and it carries queries and results between your code and the database.
- Connected model (DataReader): keep the connection open and stream rows forward-only; fast and light, best for quick reads.
- Disconnected model (DataAdapter + DataSet): copy data into memory, close the connection, and work with the copy; flexible, kinder to the connection pool.
- Disconnecting matters because database connections are scarce and shared, especially on a busy web server.
- Choose connected for a quick read-and-render, disconnected for holding, paging, or editing data.
- Memory hook: connected streams over an open line; disconnected grabs a copy and hangs up.