What's the best way of passing data from a database in a webservice from
where the serice is consumed? Do I pass it in XML and if so, what object,
exactly, do I use? Or is it better to just pass it as a dataset?
I know that behind the scenes, it's being serialized and passed as xml, so
it seems odd to be passing the data inside an xml structure, that is going to
be serialzed and put inside more xml.
I'm new to webservices though, and so I'm wondering what the best approach is.

Sorry about the duplicate posting. The website failed when I posted, so I
thought that the posting didn't take. Tried again before realizing that it
did, in fact, get posted on the first try.

"HockeyFan" wrote:

It really depends on who (technology) will be consuming yur web service.
Remember that DataSets and .NET specific so are difficult for say a Java
client to process. If however your solution is .NET based then DataSets
offer a good choice.

I personally use both DataSets and Xml - depending on requirements. I also
use objects that can be serialized.

Regards
Simon.

"HockeyFan" <HockeyFan (AT) discussions (DOT) microsoft.com> wrote

The consumer will be .Net-based. Does this mean that a dataset is the way to
go? The datasets will be one or 2 rows and no more.

"Simon Hart" wrote:

Yes DataSet's offer a good choice for .NET client consumers.

Regards
Simon.

"HockeyFan" <HockeyFan (AT) discussions (DOT) microsoft.com> wrote

Not everybody would agree that DataSets are a good solution for use in
Web Services (including me), I think Scott Hanselman describes the
situation well in his post entitled "Returning DataSets from
WebServices is the Spawn of Satan and Represents All That Is Truly Evil
in the World":

http://www.hanselman.com/blog/ReturningDataSetsFromWebServicesIsTheSpawnOfSatanA ndRepresentsAllThatIsTrulyEvilInTheWorld.aspx

Josh
http://www.thejoyofcode.com/

I must admit, I am still struggling to understand why DataSets are so bad to
use if you are developing a .NET solution front to back.

I really depends on the requirements. How do you for example handle
databinding, sorting, updating etc via a custom class?

Regards
Simon.

"Josh Twist" <josh.twist (AT) gmail (DOT) com> wrote

Hi Simon,

How convenient, I just posted about one of the reasons...

http://www.thejoyofcode.com/SOA_and_more_on_why_DataSets_in_web_service_interf aces_are_the_spawn_of_Satan.aspx

Furthermore, I don't use DataSets in server applications (they're great
in thick winforms that don't use services) for these reasons:

http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://aspnet.4guysfromrolla.com/articles/051805-1.aspx



Simon Hart wrote:

One reason is that they limit your ability to scale your application with
minimal application changes. Suppose you wish to pass a NET 2.0 DataSet
today, so you set up a web service consumer that can receive a NET 2.0
DataSet.

Now, what happens if (and when) you'll want to replace that NET 2.0 DataSet
with a NET 3.x DataSet? You'll have to change your consumer as well. Or
better yet...What if down the road, you want to swap out the NET web service
consumer with a Java web service consumer?

By keeping the proprietary stuff within a software tier, you leverage your
ability to scale your application later on.


"Simon Hart" <srhartone (AT) yahoo (DOT) com> wrote

So the end result really is it allows you to adapt to change more easily.
But what about the functionality that is lost as a result of creating custom
classes, such as sorting, searching, merging etc and all the other
wonderfulthings you can do with DataSets.

I think what alot of these arguments is missing is a project depends on
requirements and often a rich feature set that is delivered on time and
within budget. If DataSets are not used this functionality is lost which
means the developer has to replace it. This of course results in either loss
of functionality or a more costly and lengthly time scale.

So far I have not seen the equivilent of a custom class and a DataSet that
warrents the extra effort.

Regards
Simon.


"Scott M." <s-mar (AT) nospam (DOT) nospam> wrote