views:

560

answers:

6

Hi,

So from what I've seen about services, custom objects seem to be the way to go when the service is written to return data. If I am writing a service that will be used to 1) populate a database, or 2) provide information for a web site, is there ever a use for returning a dataset/datatable as opposed to a list of custom objects with all of that information?

thanks

+3  A: 

I think the biggest problem with sending DataSets over the wire, assuming you "own" both ends, is the sheer "weight" a DataSet carries - with it's relationship capabilities etc. it does far more than transport data. A simple collection of objects should be substantially more lightweight.

If you don't "own" both ends, or may have other clients using your service, then the DataSet is an interopability nightmare.

If you don't care about either of these issues, and you feel that a collection of objects is too much "work" (e.g. if you're just going to translate it back to a DataSet on the other end) then that's your call.

There's a good article on it over here.

Steven Robbins
I only own one end, and the consumer of the service is using .NET 1.1
Especially in the case that you don't own one of the ends, you are completely removing the ability to version your contract. You are etching your service in stone.
Anderson Imes
A: 

Custom objects make it easier on your clients. DataSets/DataTables make it easier on you.

I think that you should base your decision on who you want to make it easier on.

Moose
A: 

Despite the popularity of ORM, I return datasets. Returning custom objects means a lot of work on your part duplicating functionality already present in the dataset class. Datasets do an excellent job of representing table-based data in memory.

MusiGenesis
+3  A: 

The only time I ever return DataTable / DataSet over WCF is where I have something where it is just impossible to know the schema in advance, or they simply isn't any benefit. 99.99% of the time I'll work with regular DTO classes, since that gives a good blend of performance, simplicity (to debug) and interoperability.

I've been working with WCF since the 3.0 CTP... I've used DataTable via WCF only a couple of times... I felt slightly dirty about it, but for the cases in question there was simply no return-on-investment on doing it the hard way.

Just note that it will be very hard for a non-.NET client to consume them.

Marc Gravell
+1  A: 

Questions like that are hard to awnser but in general no you do not want to return a dataset from a webservice. Insead try to return a business object. Something that makes sense to a business person as a concept like a Order class. The reason for this is that in general you do not want to couple the webservice client to the implementation details of the application providing the service. The client cares about orders not about how those orders are then structured in the database. This would create a tight coupling which is opposite to the spirit of a webservice. Secondly if the client using the webservice isn't a .net client then they would end up with a pretty nasty XML to create/parse in order to read/write the dataset which wouldn't be a datatype on their platform.

olle
+1  A: 

I would not use datasets over web services for the following reasons (they may or may not be relevant in your case):

  • Datasets are MS technology, what happens if you want to call the web service from a java client?
  • You do not have control over the changes that the client makes. You are just getting back a list of changes that are being persisted to the database.
  • Datasets include alot of information that may not be required, leading to performance problems.
Shiraz Bhaiji