To return a dataset in a web service or not?

Question

Is there a best practice in regards to returning (or NOT returning datasets) from .NET web services? One camp says that we should promote interoperability and use XML schemas to define the web service payload, the other camp says we should return datasets because it's straightforward in Visual Studio and get's the job done more quickly.

Some arguments in the anti-dataset camp:

• Datasets are not WSI compliant
• Datasets seem to rarely be supported by 3rd party software

Some arguments in the pro-dataset camp:

• They are very handy and quick to build in Visual Studio.
• We (my company) only develops in .NET so interoperability is not an issue
• Datasets on the client side have advantages for ease of use

Answer 1

I would be in the camp that you shouldn't send it, but this is a decision that will be made based on what is important for your company.

If you design a webservice API that is basically a contract between the company and clients. So, some people in the company may start to use this API for mission critical operations.

Then you get a request to have it work over a Blackberry. Now you have to change the webservice, which may break other applications, causing a ripple-effect.

So, if you are certain that you will never need to support other platforms, other than .NET, then you may just go with the first option.

Answer 2

Use Datasets? I would say a thousand times no. They are not interoperable with other toolkits (as you mention). Sure, your only consumers right now are .NET but things can change quickly and it's nice to be prepared.

See The XML Files for some reading.

Also, if you are developing new services, write them using WCF. Then you can expose them however you want. If the service and consumer are internal and both are .NET then you can use the TCP binding for better performance. Then later on when someone else wants to communicate with your service you can add a new web service binding so their Java app (for example) can interoperate with your service. See Choosing the right WCF binding for a handy flowchart.

Answer 3

I'd go for no datasets as well (just like most of the community here). Like James say, you're never sure that your service will be consumed only by .NET applications. Main reason of a webservice is that it's a standard that can be used by all technologies, if you create it correct.

DataSets also breaks the ideas of domain driven design and seperation of layers and are therefore less attracted as they used to be in the beginning. I only use them for demos that needs to be quick and dirty ;)

If you really want an "easy" way of developing (within the IDE) and still be conform with all the standards, consider creating your services with WCF.