Web Services and DataSets

Some interesting discussions around datasets and webservices are happening in the blogsphere.

First, Scott Hanselman says you should not use them from WebServices. Then Ted Neward agrees, and then he disagrees.

Meanwhile, Doug Pourdy gets to the point and says that the real root of all evil are PurchaseOrders, and Clemens admits he does not use them anymore (that one hurted me! ;)

I'll be bold and try to wrap this up.

a) DataSets can be consumed from a Java client with no effort given you follow the recommendations in DataSets, Web Services, DiffGrams, Arrays, and Interoperability. Is probably not the best performant solution but it works.

b) From the four basic CRUD operations, there are two that are very easy to expose in webservices, which are the 'C'reates and 'R'etrieve operations. 'D'elete and 'U'pdates are easy if you don't try to cover optimistic concurrency scenarios. They are very hard if you want to cover them and you need the older values, i.e., I retrieve an order, I change it, and send it back, my optimistic concurrency strategy could need the old Order values in addition to the new ones. The only way that I'm aware this can be done well today is with a diffgram, so if you don't use DataSets you need to write something similar by yourself or keep state in the server. Anyway, I think most people just exposes the Create and Retrieve operations in webservices.

c) If you decide to not to use DataSets, you should _not_ expose your domain model. That's what Doug and Ted mean. You need to explicitly describe the view of that object model that you want to use, and do it with XML Serializable data types. Doing it with DataSets forces you to make that explicit. Of course, is not the only way, you can map it to simple classes, which leads me to the following point

d) If you are very performance oriented, you only do the C/R operations, and you like to have fine tuned code in each scenario, then Clemens approach is the best. Write the business logic in a stored procedure and load a simple type bound to the data you need for that service. I think this is overkill for projects where you can buy enough hardware to run the application with no problems and you prefer to save in programming hours.

e) If you are doing just ASP.NET applications with mostly read-only data, then DataSets aren't that great. They are easy to work with and easy to bind and cache, but is not that different from working with a simple collection. If you are doing updates of hierarchical structures (i.e. an Order + Order Lines) then it makes more sense, as you can keep track of which row was added, changed, etc). If you are doing Windows Forms apps, then they make a lot of sense. The problem is that I want to have only one business logic layer and reuse it from ASP.NET apps, Windows Forms and WebServices, so I need to choose which data structure I should use. DataSets are quite usable from all of them. Plain CLR objects are not.

Risking to sound arrogant, I'd say that there are two levels of DataSet 'understanding'.  The usual trip is first to like them (some people skips this one;), then to see them as an ugly thing designed for novice programmers and move to .net plain classes. Then some people reaches to the next level of enlightment and understands that they are really a very powerful and versatile data container that works OK in most scenarios.