>Michael,
>
>Yes I did say that using properties could address the issue of
>data binding being made easier, but now I am saying that the data
>binding is made easier and the price is paid in other areas.
>
>As an example, that is probably a poor one but.... If the middle
>tier is to really isolate the front end from teh back end we should
>be able to change the field names on the backend without needing
>any changes to the front end. If we are using properties in the
>middle tier that correspond to the back end field names and the front
>end is binding to those properties then making a change on the back
>end requires changes also to both otehr tiers.

Ah, I understand what you are saying. However, in order to divorce the back-end data names from the front end you could keep the property names the same, but merely change the method that updates those properties on the bizobj. If you made the names of the data properties meaningful rather than a copy of the field name it would make more sense, in any case. The front-end would still bind to the same properties.

While we are in the topic of n-tier design Microsoft has an interesting series of articles discussing just this issue. The article takes a monolithic application and redesigns it as a 2-tier and then 3-tier app using Visual Studio. It can be found at:

N-Tier Example