This question is locked. New answers and comments are not allowed.
Hi,
In Northwind sample web application we have Telerik's reverse engeenared classes (DAL layer), BO classses that correspond to the before mentioned classes but without any dependency from Telerik (Business Object Layer), and BLL layer, that contains business methods behind an interface (INWDataProvider).
In BLL, ClassNameAssembler classes convert DAL classes to BO classes.
Wich is the result? The WebUI layer will independent from BLL - DAL, ie. we can replace them, when we want to change the DataAccess technology.
Why we can't use directly the DAL objects when they depend only from system and system.collection generic, instead of using BO and converting every DAL objects to them?
Thanks in advance
Gabor
In Northwind sample web application we have Telerik's reverse engeenared classes (DAL layer), BO classses that correspond to the before mentioned classes but without any dependency from Telerik (Business Object Layer), and BLL layer, that contains business methods behind an interface (INWDataProvider).
In BLL, ClassNameAssembler classes convert DAL classes to BO classes.
Wich is the result? The WebUI layer will independent from BLL - DAL, ie. we can replace them, when we want to change the DataAccess technology.
Why we can't use directly the DAL objects when they depend only from system and system.collection generic, instead of using BO and converting every DAL objects to them?
Thanks in advance
Gabor
1 Answer, 1 is accepted
0
Hi Gabor,
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,
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.
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,
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.