The first service in DNN I explored for customization was the Role Service. That service has RoleController under Security in Components, a DNNRoleProvider in a separate project named Provider.Membership.DNNProvider and a DataProvider again in a separate project named Provider.Membership.DataProvider. The norm here is that the UI CodeBehinds call the RoleController, which uses the DNNRoleProvider which in turn uses the DataProvider, i.e. an architecture something like: Controller -> ServiceProvider -> ServiceDataProvider However, in the case of Caching service, it is the BPCachingProvider that uses CachingController which uses the DataProvider, i.e. ServiceProvider -> Controller -> ServiceDataProvider Now, which way it should be? Should controller use ServiceProviders, or ServiceProviders should use Controllers?? In majority of the cases (Role, Profile, Membership), I have observed that it is the Controller that calls the ServiceProvider. So, why an exception in Caching Service? One more thing I have observed is that there is a common DataProvider for multiple services (e.g. Membership, Profile & Role Provider share the same Abstract & Concrete DataProvider). Shouldn't there be separate Abstract DataProviders for each service. e.g. I want to customize how the Lists are handled in the database (whose abstract methods are present in the main DataProvider class of DNN), but have no option but to handle Portal, Tab, SearchEngine, Files & a hec lot of other Methods that I dont want to play with??? Would it be a good idea to inherit from the main SqlDataProvider of DNN, override List Handling methods & leave the other ones upto the base class??? |