Hello Robert Lautenbach,
Surely, you can use the persistent classes directly in your upper layers if you do not like the approach used in the n-tier demo. One of the reasons to use such duplicating transport objects was that OpenAccess did not have support for "shared columns" by the time this example was published, i.e. you could not have both a CustomerID foreign key field and a Customer reference. While using the foreign key field is much easier in web and(or) disconnected scenarios, using object references is more appropriate for managing and navigating through the data in the business logic. The approach used in the demo pretty much solves that problem as in the transport objects you can expose the foreign keys but work with references in the data provider. Now OpenAccess supports shared columns, so you should be able to directly work with the foreign keys defined in the persistent classes.
However, the main advantage of using transport objects is that you can limit the data exposed by these objects and this way decrease the network traffic which should not be underestimated.
If you want to add validation to you classes, you can do that in both the persistent or business objects. If you plan (or want to have the option) to switch the data access layer at some point, maybe it is better to have the validation over the business objects. This way you will not have to rewrite it in the new data access layer. If you are using however, only one set of persistent objects, putting the validation logic there is fine as well.
As you can see those questions do not have common answers and they usually depend on the exact application that you have to design. Please feel free to contact us if you need more details.
All the best,
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Public Issue Tracking
system and vote to affect the priority of the items.