Mark is making the case for using DataSets.
In working on frameworks for the past several years, I've had many of these arguments before. The question is always, why should I adhere to your model when I think it has flaws and I think or know I can do it better?
The fact of the matter is that, in hindsight, there are always things you can identify better ways of doing. And chances are that the original author - someone more intimate with the problem domain - sees those same shortcomings and is already looking into them.
It's human nature to be biased towards our own solution. When dealing with a platform- or industry-standard construct like the DataSet, we need to consider more than just the time and effort spent implementing your solution. You've now introduced a non-standard element into the project in place of a standard element.
All of a sudden, new developers have a greater learning curve because, even though they are familiar with the DataSet object, they don't know your version of it. You effectively render the experience of a new developer useless (or at least less useful). You also forbid yourself from using certain third-party components, let's say, because they too can consume a standard DataSet but know nothing about your version. Then there's the additional cost associated with maintaining and enhancing your version. I could go on, but you get the idea...
Now, that's not to say that in fact you really have a great idea and in this case it's worth pursuing. I'm not trying to discourage innovation and blindly following Microsoft's lead. I'm just saying we should be weary of deviating from a standard solution for what sometimes looks like the sake of doing things differently.
Another thing I wanted to comment on with regards to Mark's post was the when he says that "the second example [using untyped DataSets] is slower than the first [using typed DataSets]." A typed DataSet is just a programmatic nicety. It just adds a wrapper around the base DataSet object to you can check types and whatnot at compile-time.
If you look at how this actually implemented though (and I don't have specific benchmarks for this), I would highly doubt that a typed DataSet is in fact any different from using an untyped DataSet.
Take Mark's example of the DataSet. When he calls:
myDataSet.MyTable[0].UserName = “MyName”;
this maps down to a property accessor that looks something like this:
public string UserName {
get {
try {
return ((string)(this\[this.tableBook.isbnColumn\]));
}
catch (InvalidCastException e) {
throw new StrongTypingException("Cannot get value because it is DBNull.", e);
}
}
}
As you can see, this doesn't really do anything special that you wouldn't be doing anyways. All it really buys you using a typed DataSet is a simplified programming model and some compile-time type-checking.