Are Typed DataSets a Viable Data Tier?
Typed DataSets in ADO.NET 2.0 are easier to work with and much simpler to use than Typed DataSets in ADO.NET 1.0/1.1. The basic premise behind a Typed DataSet is that an XSD (XML Schema Definition) file is created that models a database schema or a subsection of the database schema. This XSD is then converted into a C# class at build time, is usable at runtime, and provides IntelliSense-aware members. In addition, we thought we might be gaining a big benefit with strongly typed members. Unfortunately, the strongly typed members are really just a facade. Under the hood, the Typed DataSet is still just a DataSet that stores everything in terms of objects. The amount of unnecessary typecasting that goes on with Typed DataSets was unacceptable.
To get data into a DataSet, you normally use a DataAdapter. In the case of a Typed DataSet, there are specialized TableAdapters that are responsible for querying the database, filling tables, and persisting changes back to the database such as inserts, updates, and deletes. In Listing Two, which populates a Typed DataSet, there is no inline clue, cue, or faint reference to what data is being populated other than the method name. Because I wrote the code, I know that GetAllBookmarksWrtUser on the BookmarksTableAdapter class actually refers to a stored procedure in my database called moniker_GetAllBookmarksWrtUser. Thankfully, I had some naming conventions that made things easy to decipher. But what if I was looking at this code and wasn't the author? Or what if I didn't have direct access to the database? I would have to spend considerable time digging through the contents of the Typed DataSet to figure out everything that is going on. I would much prefer to be able to see the query from the same perspective as the code that binds the query results to the GUI. My usual habit of right-clicking a confusing method (such as GetPopularTags) and choosing "Go to Definition" doesn't help me here. Why? Because all it does is take me to the definition in the Typed DataSet, which just creates more spaghetti code, creates a generic data adapter, and fills based on parameters. There's no useful information. I have to crack open the XSD for the Typed DataSet to find out what's really going on.
BookmarksDataSetTableAdapters.BookmarksTableAdapter bookTA =
new BookmarksDataSetTableAdapters.BookmarksTableAdapter();
BookmarkList1.DataSource =
bookTA.GetAllBookmarksWrtUser( User.Identity.Name, pageIndex,
numRows, ref totalBookmarks);
TagDataSetTableAdapters.TagsTableAdapter tagTA =
new TagDataSetTableAdapters.TagsTableAdapter();
TagList1.DataSource =
tagTA.GetPopularTags(DateTime.Now.AddDays(-30), User.Identity.Name);
recentTagsList.DataSource =
tagTA.GetRecentTags( DateTime.Now.AddDays(-30), User.Identity.Name);
The code to update using Typed DataSets is straightforward. Make the changes to the object. The TableAdapter can then convert those changes into a SQL execution (inline SQL or stored procedure) and send that to the server. Typed DataSets are extremely powerful, but in any data tier I plan on using with any regularity within the enterprise, I want true and legitimate members on classes (not just typecasting wrappers!). I want model layer abstraction. I want real data types instead of typecasting, and most importantly, I dislike the fact that the information being retrieved is extremely difficult to find. You need to dig deep into the XML of the DataSet (which you can't even see in VS 2005 without explicitly requesting the XML editor) to see the queries that are being executed against the server. Even after you find the queries, they are in a syntax that is painfully difficult to read. This entire infrastructure makes difficult the task of reviewing code, analyzing queries, and even inferring what data is flowing and where it's flowing to.
