Doug Purdy posted an amusing response (and here) to the whole "DataSets are evil" argument.

To be clear, my aversion to DataSets has nothing to do with their use in web services, but rather as an overall architectural principle. As he points out (and Dare reiterates), once it escapes your application we're simply talking about schema and XML data. (Note: it's interesting to question what "it" represents in the previous sentence; it sure as hell isn't an instance of a DataSet once it reaches the wire!) The programming model is an implementation detail, and is certainly hidden behind an interface.

So if application edges are rigid and abstracted by an interface which represents data as XML, who cares in what fashion such XML is constructed? Once could - if so inclined - represent objects internally in a picture perfect domain model, yet serialize them over the wire in a horrid alphabet soup of nonsensical tags; and, conversely a DataSet could manifest on the wire as a beautiful schema-driven thing of wonder.

So, again... who really cares?

Well, I do. My comments were made focused on proper separation of concerns within application boundaries (e.g. between tiers) and through the prism of proper domain modeling. So while advertising this as a web services-specific problem is a miscategorization, I still firmly believe it's a problem.

But then again, it's all about value delivered to the end consumer. My beliefs and experience are simply that careful domain modeling more often than not results in better value and agility in the end product. And thus, I stick to my story.