Architectual advice on Web Service. DataSet vs Business Objects?

  • Thread starter Henrik Skak Pedersen
  • Start date
H

Henrik Skak Pedersen

Hello,

I am designing a new architecture for our application. The application
consists of a Web Service which is providing data for an ASP.NET Web
Application and a Windows Application.

So now is the big question should I pass datasets or generic lists og
business objects between the tiers. What is the your recommendation?

I am using .NET 2.0.

Thanks

Henrik.
 
G

Guest

Going through the same selection process myself, I have only just elected
for an ASP.NET WebService over using Remoting on the grounds of an MSDN
article I found recommending against the use of Remoting in a internet
environment.

Now Im deciding between DataSets vs Custom Entities...the list is as long as
your arm in terms of the pro's and con's of each, the general consensus
amongst developers all over the web seems to be, according to my summary of
2 weeks worth of research;

1. Datasets
Are claimed to be a quick kludge, for small scale projects with a tight
deadline and specific functionality and also go against principes of SOA
(http://en.wikipedia.org/wiki/Service-oriented_architecture) which seems to
be the current vogue.

They are .NET specific so each end must be a .NET based client (in your case
no problem) according to most they are classed as a bit chunky and
unwielding, often providing large amounts of extra meta data that has to be
sent over the wire along with the actual data (change information for
re-merging when passed back to a server for instance)

2. Custom Entities, wont DataBind to components as nicely as a DataSet
without you having to create some custom collection handlers which interface
to BindlingList and others, simple readonly bindling can be achieved quite
easily however with a simple ArrayList or List<T>. They are lighter and
generally faster to retrieve and send down the wire, in fact some articles
claim that developers find .NET runs faster using a DataReader to manually
extract and populate a list of Custom Entities and Serialize them than by
filling a Dataset and Serializing them. You have total control over the
serializing process also, with the ability to leave out bits and pieces and
give XML nodes different names to your properties etc. Since theres no
Database Specifc information in your custome entity all the persistence and
concurrency must be handled by you when changes are sent back up the wire.

3. Then theres Typed Datasets which are kind of somewhere between the two,
you get the nice Intellisense that you would get with your Custom Entities
but you also get the Database Metadata for Persistence - I beleive, so they
are worth checking out also.

You should really look at using an ORM framework, such as Rocky Lhotka's
CSLA www.lhotka.net , the various frameworks at
www.mygenerationsoftware.com but there are many more, some commercial
offerings, the majority of these tried and tested frameworks some of which
power large enterprise projects adopt custom entities and not datasets as
their preferred data containers.

Great articles on Custom Entities vs Datasets
http://objectsharp.com/Blogs/barry/archive/2004/02/10/273.aspx
http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/
http://www.lhotka.net/WeBlog/ThoughtsOnPassingDataSetObjectsViaWebServices.aspx

Report back how you get on

Chaz
 
H

Henrik Skak Pedersen

Hi Chaz,

Thank you very much for you reply.

I still kind of see the typed dataset as the best solution. It look like the
result in the receiving end is very similar to custom objects. But they are
much easier to create, maintain, sort, filter, ect. I think that there are
many standard advantages of using datasets.

But I have not made up my mind 100% yet :)

Thanks
Henrik.
 
J

Javier G. Lozano

How much data are you planning on exchanging for your application?
This will have a big impact your decision. Remember you need to think
about exchanging your domain model and whether it will make more sense
to do it through a relational view (DataSet) or entity view (custom
objects).
 
S

Steven Cheng[MSFT]

Hi Henrik,

I also quite agree to Chaz's suggestion. And for webservice which will be
consumed by different heterogenious clients, the "interoperability" is the
most important. And there now comes up the "Contract First" concept which
provide a guide on developing webservice that has high interoprability.
Here are some resource on this topic:

#Contract-First Service Development
http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/

#Contract First web service design
http://adrianba.net/archive/blog-4a221b1eee2d4fc5894aeb3e0cc991d1.aspx

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

Josh Twist

Hi All,

I've linked to this article a number of times on these groups because
it sums up my passion against using DataSets in Web Services:
http://www.hanselman.com/blog/Retur...AndRepresentsAllThatIsTrulyEvilInTheWorld.asp

I hope that swings your decision :)

Good luck whatever you decide.

Josh
http://www.thejoyofcode.com/

PS If you're still thinking of using DataSets - here's why I steer
clear of them altogether in ASP.NET development:
http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://aspnet.4guysfromrolla.com/articles/051805-1.aspx
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,236
Members
46,825
Latest member
VernonQuy6

Latest Threads

Top