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???

And exactly for avoiding that (making changes to the core), I thought of inheriting the existing DataProvider or Provider classes, then override whatever methods I wanted, and leave the rest to the base implementation.

Part of the reason I need to do this, is because DNN segragates portals from each other completely, and I have a situation where I need to share some data between portals (like Lists, Profiles etc.). I have also created another thread on a related problem:

http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/111/postid/230004/scope/posts/Default.aspx

Also, the Provider architecture of DNN allows the Service Provider (e.g. DNNRoleProvider) to be replaced through web.config, but not the DataProvider. Would it be possible to just replace the DataProvider (e.g. the SqlDataProvider implementation for Profile service of DNN) without touching the ServiceProvider or the Core Code.

The reason I dont see this to be possible, because in the following CreateProvider() method of  Security.Membership.Data.DataProvider

        Private Shared Sub CreateProvider()
            objProvider = CType(Framework.Reflection.CreateObject(ProviderType, ProviderNamespace, ProviderAssemblyName), DataProvider)
        End Sub

the Provider namsespace & assembly name are hardcoded to be DotNetNuke.Security.Membership.Data from the same assembly???