passing data in an ntier application

Question

How do you pass data to layers in an n-tier application? I have mapped out 3 different methods.

A) generic .net objects generic data tables, Hashtables, generic datasets, strings, ints etc... then using the datasets to fill your business objects which get sent to the UI layer.

alt text http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro- No extra layers needed Con- Have to work with Generic datasets and tables in the business layer

B) using an entities layer that the other layers would reference. This layer would contain either strongly typed datasets or Plain Old C Objects. The objects would be mostly container data and very little logic. these would be the same objects sent to the UI layer.

alt text http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro- working with the same classes in all layers Con- adding a reference to entities.dll to all layers

C) use data transfer objects (conatiner objects only) defined in the DataAccess Layer. then using those objects to fill business objects which get sent to the UI layer.

alt text http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro- the business layer would not have to work with generic classes Con- working with two types of objects and you would have to hydrate the business objects with the transfer objects

We had a discussion at work and wanted to see what the community thought. I also added a link to the dabbleboard. please copy and create instead of editing.
Thanks

Answer 1

If you're using a layered approach, meaning all layers are (essentially) executing in the same process space and there is therefore no marshalling/serialization, I'd go with approach B. Create a separate module for your entities upon which all aspects of your program depend, and couple to that.

If, however, you're using a tiered approach as your title suggests, meaning there are process and/or network boundaries that are crossed, I'd suggest you go with approach C. You're not really passing instances around, you're passing copies, so any benefits you get to coupling to the same object, like observable options for, say, an MVC approach, are lost anyway. Better to define data APIs at every tier level than to try to use the same class all around.

Answer 2

Great question - as always, the answer has to be "it depends".

On the type of application, and whether there is really a need to have business objects (Entities), as opposed to transfer objects (ie dumbed-down business objects that correspond more to database entities).

Traditionally, I would have argued that you always have a need for generic data sets (or data tables), purely for performance reasons. Whenever there is a need to work with, display, or manipulate larger sets, the traditional strict OO way of instantiating large numbers of business objects failed.

However, since I started to work with Linq to SQL, my paradigms have changed. There is no longer a need for this at all, since the Linq model can be everything - business objects, transfer objects, and generic datasets. I have not explored yet how well this works in really large applications, and whether there should be a need to isolate front-end code from the Linq model. I have had discussions about it with colleagues, without really finding an answer either way.

Answer 3

I like option C but it also gives me pause for two reasons:

1. I have to spread the knwowledge of what the properites are in too many places.
2. DTO's have to be serializable, which isn't terrible but still a consideration.

Answer 4

I am assuming all 3 layers exists within the same app. In java atleast I've used Hibernate for Data access and used those data beans in all layers. (option B) It makes sense to be able to reuse your entities in your layers.