passing datasets?

[HockeyFan]

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.

 

[HockeyFan]

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.

 

[Simon Hart]

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]

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]

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

Regards
Simon.

 

[Josh Twist]

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/Retur...ndRepresentsAllThatIsTrulyEvilInTheWorld.aspx

Josh
http://www.thejoyofcode.com/

 

[Simon Hart]

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]

Hi Simon,

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

http://www.thejoyofcode.com/SOA_and...ervice_interfaces_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

 

[Scott M.]

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]

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.

 

[Josh Twist]

Hi Simon,

Firstly, sorting and searching custom object structures these days is a
doddle and will get even easier with the release of LINQ, check out
this link:

http://blogs.thinktecture.com/cnagel/archive/2006/03/11/LINQ01.aspx

Taking your RAD arguments though you need to think about some other
stuff. If you're after the shortest time to market:

- why use services at all - why not use Enterprise Services? it will
outperform asmx everytime.
- why use distributed computing? You can always scale horizontally and
get rid of this whole layer and just use assemblies?

If you can answer those questions and you're happy with your reasoning
then we'll never change your mind and good for you. Personally, I
prefer the agility and discoverability that that *little* extra effort
buys.

Once the service orientation penny dropped, I really understood the
value in the four tenets of SO. The third is key "Services share schema
and contract, not class" but if you use DataSets you're sharing type
(class) and this is fundamental.

Good luck whatever you decide!

Josh
http://www.thejoyofcode.com/

 

[Scott M.]

I think you are missing one important point here Simon...

We're saying that *passing* a DataSet is not the greatest idea. No one said
you couldn't pass XML and then read that XML into a DataSet in your web
service consumer. This way, you still get to use all of the things about
DataSet's that you like, but the actual *transmission* of data is in the
non-proprietarty XML format, rather than the proprietary DataSet format.

If, in the future, the consumer encounters any of my scenarios (new DataSet
becomes available or different platform consumes the web service), you won't
have to change anything about your web service.

 

[Simon Hart]

I do understand the points here which I will add are very valid. I never
snub other developers ways of doing things, I like to take every peice of
information on board then make my own mind up. Even more so when new
technologies such as WCF becomes mainstream. But it is difficult to add time
to projects that the customer will see no benefit. Convincing them that the
extra time for deliverables will be an investment for the future
enhancements etc and to support SOA is always challenging.

However, you may find this funny considering the arguments, but I never pass
DataSet's via Web Services. This is because often I am integrating with
legacy backend code via BizTalk and Enterprise Services which do not
understand what a DataSet is. Often I use Xml then either read it into an
XmlDataDocument class so I can generate a DataSet on the receiver, or I
serialize it into a class but this depends on requirements.
I am thinking of future ways of doing this (passing data). I have never
really liked passing Xml that much because it's not strongly typed. I think
Xml also has its place. I want to start looking at custom classes - this
makes the developer experience much richer and of course supports the SOA
principles. I downloaded the WinForm sample from the Infragistics site and
noticed the developer totally avoids using DataSets and creates a series of
"Info" classes which describe the data. Of course more effort is required
using this approach, but SOA is adhered to.

Going back to whether DataSets should be passed via Web Services is a quick
time to market solution which allows rich functionality through little
development effort. So I still do not disagree with doing it, like most
things technical, whether to use this method or not, depends.

Regards
Simon.