We help IT Professionals succeed at work.

3-tier architecture question: datasets or business objects between tiers?

rj2 asked
Medium Priority
Last Modified: 2013-11-12

In 3-tier architecture, what is best to send between the tiers, XML, Datasets or custom objects and why?

The book "Expert C# Business Objects" advocates objects.

Which other books should I read to get a good overview of my options?
Are there any particular problems with passing business objects, is there a backside that the author don't mention?
I've got the impression that typed dataset is a rather common choice on what to pass between the tiers?
Watch Question

I think this varies in many ways. Still see what microsoft says regarding this issue:~

Recommendations for Data Access Strategies:~  


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Will using business objects result in having to write more code than if using datasets?
See following, exactly what you're looking for..

Designing Data Tier Components and Passing Data Through Tiers:~

This is a quite interesting question. Unfotunatly I have not real good answer nor even a suggestion. I guess for most OO languages the answer is clear the use Objects.

But one problem with objects is: They have to be constructed and in the end they get transformed to something not very objectish e.g as a row in a table.

If you look into popular things like Ruby on Rails, JSP and the like you'll see that a lot of time is spend on

getting textual input -> construct the object -> work on the object
-> flatten the object to put them into an database.

We face a problem OO is quite poor on. Data persistence, agreed there do exsit thousand of solutions for that, but it shows that there is not "common" way. Agree also there do exist OODBs but they are not in wide-spread use.

I once though why should one use anything else but objects today I'm more thinking what the hell do I have from OO?

I think you should read Philip and Alex's Guid to Web publishing to get the point.

I feel with the Web this things even get worse (every day). I'd argue even today most of the information is still text, words one after the other. All in the Web is more or less based on "strings" So for simplicity I 'd argue the best bet is to use something which can do the most crazy things on strings with the least effort.

On the othe hand one other data-structure is ubiqueous, tables, maybe it's really time to get back or progress to somthin which can handle in easiest ways. persistence would nearly a no-op because writing tables in any form is one of the easiest tasks.

Well, you've effectively just asked the BIG QUESTION on how to model your domain layer, and identified the two alternate approaches.

The design-god himself, Martin Fowler, says (I hope I get this right) that it doesn't matter so much which one you use - your decision is probably best made by the tools you have. .NET makes datasets very easily available, so for RAD, that may be the best choice.

I would recommend his book Patterns of Enterprise Application Architecture, it goes into it with a nice balance for each model.


Oh, by the way, don't concentrate too much on "X or Y or XML" - Xml should be regarded, in this case, as a persistence medium for serializing and transporting objects that can then be deserialized at the other end back into in-memory objects. As such the alternatives are binary data, XML etc. Your main choice then comes back to custom Business Objects, or Datasets.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.