web service / wcf service, is it ever better to re

问题:

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

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

I'm totally shocked at the number of people who do not realise what an atrocious decision it is to have a web service that returns a DataSet.

A DataSet is a custom .NET type. The whole point of a web service is that it can be called by any language on any platform.

Put simply, if a web service returns a DataSet then it isn't a web service!