This question is locked. New answers and comments are not allowed.
Robert Lautenbach
Top achievements
Rank 1
Rank 1
Robert Lautenbach
asked on 03 Mar 2010, 09:26 PM
I've taken a look at the n-tier application example code project. All in all, I don't like the idea of maintaining two disconnected sets of duplicated classes, one set in the persistent class data access layer and another in the business logic layer.
It's a total duplication of the same class definitions from a property perspective. And it also separates some logic away into yet another layer from the persistent classes. So if somehow code directly hits my persistent classes, the results will be different than code hitting the business layer classes. For example, if I build pre-commit validation into my classes, if I am using business layer that validation fire but it will not fire if the persisted classes are ever called directly.
After that long winded intro -
- What basic architecture approaches are you taking with OpenAccess?
- Are you putting extension functions directly into your persistent classes?
- Are you creating another kind of wrapper class to mask the persistent class in your web or windows applications? If so please link or give some detail.
Thanks!
1 Answer, 1 is accepted
0
Accepted
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,
Alexander
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? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
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,
Alexander
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? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.