InformIT has a great, five-part article about this debate. I have yet to
work on a .NET contract gig and not have this debate with other
developers. Personally, I'm quite fond of typed-datasets. Why? There is a ton of
built-in features that you get for free: serialization, sorting, bindability,
filtering, schema, XML integration, relations, and validation. Heck, even
Microsoft released Duwamish books as an enterprise sample application that used
the DataSet (albeit wrapped similar to a typed-DataSet) in its code. Perhaps the
most compelling reason that I bias towards using typed-DataSets is that most
developers tend to f--k up when creating their own custom class/collection for
the same purpose of a DataSet. I've seen first-hand what happens when a mediocre
developer tries to model a class hierarchy after a database - it's recipe for
disaster. Even an experienced developer is prone to bugs, so why re-invent the
wheel with the increased probability for error if you don't have to? As a
disclaimer, I'm not saying the DataSet is a cure-all; however, in the majority
of circumstances (especially large collections of data) I'd like to see someone
benchmark a real performance gain using custom collections. Couple that with you
as a developer having to write your own "gue" to handle the aforementioned
functionality that comes free with the DataSet, and let's weigh the pro's and
con's. I'm open-minded about this debate, but not so open minded that my brain
will fall out. So far I've seen that the proof is in the pudding with the
advantage going to utilizing DataSet objects from what I've seen working with
other people. The project I'm working on right now, for example, was split into
two camps: custom collections versus typed-datasets. Yes, this should have been
discussed up-front, but in the haste of cranking out a solution against a very,
very tough deadline the app was written and now it's baked. The vast majority of
bugs I've been fixing is in the code camp belonging to the custom collection
folks. Extension of functionality has also been an issue. Ever wanted to sort by
a class property in a DataGrid and have to write that IComparer code to do the
sorting? Essentially, these custom collections are doing the same thing I could
do with the DataSet and not have to write my own filtering and sorting code.
Anyway, here's an excerpt from the InformIT article:
Microsoft most often recommends ADO.NET DataSets as the way to go...I
have talked to Microsoft about this because of their pretty clear
recommendations, and they've said that they are actually pretty fond of a
custom object-oriented format. In their view, the problem is that it's much
more complicated and more risky to go my route. After all, DataSets come
with a lot of built-in functionality for free. A lot of the literature (for
example, Fowler's book) supports Microsoft's view that building a custom
object-oriented format requires work and is risky.
MSDN:
It is recommended that you avoid designs requiring you to transfer
data in a custom object-oriented format, because doing so requires custom
serialization implementation and can create a performance overhead.
Generally, you should use a more data-centric format, such as a DataSet, to
pass the data from the data access logic components to the business layers,
and then use it to hydrate a custom business entity if you want to work with
the data in an object-oriented fashion. In many cases, though, it will be
simpler just to work with the business data in a DataSet.
