I understand DataSets. What is a TableAdapter for?
In the last post I discovered the Strongly Typed DataSet. There’s little reason to not using typed DataSets because Visual Studio will generate the necessary code for you and it only takes a moment. Yes, really. The DataSet wizard will create SQL statements or stored procedures or use existing stored procedures. Writing the Data Access Layer (DAL) of your application has never been such a painless task!
TableAdapter – the fifth class
When you create a DataSet using Visual Studio 2005 it will create 5 classes. For example, say you point to the Customer table of your database (named StoreDB), you will end up with:
StoreDBDataSetCustomerDataTableCustomerDataRowCustomerRowChangeEventCustomerTableAdapter
The four classes, i.e. each of the classes above except for the DataSet class, are repeated for each table defined in the DataSet.
The TableAdapter is the strongly-typed equivalent of the standard DataAdapter. Nice eh? I’m only just getting my head around this and it is making sense, slowly.
Here’s a quote from an article by Brian Noyes that succintly describes what a TableAdapter’s purpose is:
Finally, and perhaps most importantly, when you create typed data sets in Visual Studio 2005 from a database, you also get a table adapter type created for each table that you add to the data set. A table adapter is a full fledged data access component that lets you retrieve and update data from the database. It encapsulates a connection, a data adapter, and a set of command objects that allow you to execute queries to the database. I’ll get into more detail on table adapters in a little bit.
Further Reading
Jackie Goldstein has a good tutorial on the TableAdapter. It took me a couple of reads to understand what benefits the TableAdapter brings and how it saves me from writing lots of code, which is always worth the effort.
Update: Listen to Jackie Goldstein speak about the TableAdapter on DotNetRocks podcast. Skip to 44 minute 40 seconds in the audio file to get straight to the subject at hand.
Datasets are absolutely not worth learning and not worth your time. the only benefit (maybe) is code generation, which is piss poor at best. just look into the class that gets created, look in OnInit and you’ll notice that every object in the dataset is instantiated in OnInit, regardless if it will ever be used! Datasets are for “Drag and Drop” developers. Please do not go down that road.
cmv
February 5, 2007
I’d appreciate it if you could point me to some articles/evidence that backs your claim up about DataSets.
In the application I’m writing now, I attempted to go the route of using DataSets and TableAdapters, followed by hooking up web list controls with ObjectDataSource objects. In the end I ditched this approach because the auto-generated code couldn’t handle the GUIDs I was using in my database.
The drag’n'drop way of building things scares me a little if I’m truthful. I found myself having to jump through a lot of hoops in order to get the desired results. Though I must say that the auto-generated stored procedures is a nice touch. I’m wondering if i can get Visual Studio to generate just the stored procedures on their own rather than having to go through the motions of creating DataSets and TableAdapters then deleting them?
I’m going to follow your advice for now and write code with the keyboard. Learning this way will ensure I understand what’s going on under the hood. I’ve used DataReader objects in my DALs to get data from the database, custom objects and generic collections that hook up to Repeaters to display my data.
I’d like to find out when it is appropriate to use the visual part of Visual Studio. Any one care to fill me in?
salohcin
February 6, 2007