passing data in an ntier application

Answer 1

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 2

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.

Answer 3

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 4

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.