Sure, you can use the persistent classes directly. 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.
Hope that helps.
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.