Other references to people waging this war:
Objects vs. DataSets - Is it Really About the Technical Aspects?
excerpt:
I find that that the most interesting reasons for choosing Objects vs. DataSets are less technical, but more about the project, the developer’s methodology, and the developer’s preference. The technical reasons for choosing one over the other are pretty weak and can be resolved pretty easily.
My 2 Cents :
I guess I can acept this. I do believe that in a quick and dirty situation - datasets win. Maybe some would argue that the level of developer would favor the dataset solution - the custom object solution REALLY seems simpler to me - I guess I am just biased.
Displaying aggregates: DataSet vs. Domain object performance
excerpt:
…. I work with someone who coded a bunch of stuff using a dataset. unfortunatly, due to the complexity of the project we have to scrap all that code. Custom classes will make everything we needed done so much easier and cleaner.
My 2 Cents :
I MUST say that I totally agree with this comment. In essence I believe that classes are more natural, cleaner and in the long run - you can just embed more knowledge in them. Data sets are containers - classes are the model. I also believe that the class approach - you continually refactor and the solution is flexible - not rigid… Again - I am just biased - someone compel me for datasets….
excerpt:
Both DataSets and custom classes don’t limit what you can do in any way, and both can be used to accomplish the same aims. That said, DataSets are fantastic tools for prototyping applications and represent excellent solutions for building systems in a kind of emergency—a limited budget, an approaching deadline, or a short application lifetime. For relatively simple applications, custom entities add a perhaps unnecessary level of complexity. In this case, I suggest that you seriously consider using DataSets.In the economy of a large, durable, complex enterprise system that takes several months to complete, the cost of architecting and implementing a bunch of collections classes is relatively minimal and is incurred only once. The advantages in terms of performance, expressivity, readability, and ease of maintenance largely repay the investment. You are not bound to a tabular rendering of data. Business rules and custom business entities can’t always be adapted to look like a collection of tables. In general, you should avoid adapting data to the data container—quite the reverse, I’d say. Finally, using custom classes makes for easier unit testing because classes and logic are more strictly related than with DataSets.
My 2 Cents :
Dino is the man 1st off - 2nd - I REALLY agree with this statement as just about the best summary of all. This is what I truly believe. Dino also mentions generics in 2.0 and how much stronger the argment for classes/ collections becomes under the 2.0 framework…..
On the Way to Mastering ASP.NET: Introducing Custom Entity Classes
excerpt:
There are a number of situations for which DataSets are particularly well suited, such as prototyping, small systems, and support utilities. However, using them in enterprise systems, where ease of maintenance is more important than time to market, may not be the best solution.
My 2 Cents :
Man - I could excerpt this entire article. Read it - it really sums up my viewpoint as well.
excerpt:
Ok that’s it, everybody stop talking smack about the DataSet. As self-elected chairman of the inexistent “DataSet Preservation Fund”, I feel urged to respond to years of incorrect positioning, biased thinking and over-simplified black-and-white views. I won’t allow the “enterprise community” to make the DataSet the Clippy of .NET, so to speak.
My 2 Cents :
THis guy basically takes the other side of the “On the Way to Mastering ASP.NET: Introducing Custom Entity Classes” article - he does a weak job if arguing frankly…. Someone show me the dataset side of the argument please.. Still dont see it.
excerpt:
DataSets are bowls, not fruit. Do you really want to return bowls?A DataSet is an object, right? But it’s not a Domain Object, it’s not an “Apple” or “Orange” - it’s an object of type “DataSet.” A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It’s an object that knows a LOT about the Database. But I don’t want to return bowls. I want to return Domain Objects, like “Apples.”
My 2 Cents :
Yes yes yes…. Yes yes yes…
excerpt:
- They are very bindable. (I will give the dataset folks this - the tools do provide this. There are ways around it however - 2.0 has the ObjectDataSource and Infragistics has the excellent - WinDataSource that is useful to make ‘objects’ bind to grids easy as pie.)
- Easy persistence. (IF you are directly connecting to the DB….)
- They are sortable.(yes)
- They are filterable.(yes)
- Strongly Typed Datasets defined by XSD’s.(yes… better but 99% the rest is the same to me.)
- Excellent XML integration.(eh, I guess so.. still not ‘nice’ XML. It is generic XML - not XML for your nice object.)
- Computed Columns (OK - objects do this all the same - just as well - or better depending.)
- Relations (OK - objects do this all the same - more explicitly I would say)
- Data Validation (OK - objects do this all the same - mostly better)
- AutoIncrementing values (OK - objects do this all the same - this is trivial)
My 2 Cents :
OK - this guy has the BEST set of arguments for the dataset way. I do hear the arguments to some faint degree - but - not very strong still.