The Provider Model, Unveiled
In my previous post, I suggested that only a small percentage of ASP.NET developers could describe where the new provider model fits within a properly-architected application. I suggested that the reason so few developers understand the technology they are using is because .NET envangelists are typically magicians who perform tricks, rather than teachers who explain concepts.
I am still learning ASP.NET version 2.0, but I’ll nonetheless tell you my current understanding of the provider model. Let’s start with a look at the common layers in a properly-designed application.
The magicians will tell you that the default providers work against SQL Server or SQL Server Express, and if you want to use another database you must implement a different provider. You can then place on your .aspx page a control such as the Login control, and point that control at your custom provider. What this suggests is that the Login control is in the Interface layer and the provider is in the Data Access layer.
Even the naming of the providers suggest that they belong in the Data Access layer. The default Profile provider is the SqlProfileProvider. As one alternative, Microsoft provides a downloadable AccessProfileProvider.
If you read the magicians’ articles and blog entries, then visualising the Providers as belonging to the Data Access layer is about the only possible conclusion. But anyone with a properly-architected application will shake his or her head at the magician, and grumble about Microsoft eschewing proper architecture in favour of the slap-it-in-place-in-Visual-Studio approach. Anyone with a properly-architected application will have a User business object and probably a Role business object, both of which the above design will avoid much like a pedestrian will side-step dog turd.
The above illustrates one of the reasons I was so concerned about ASP.NET version 2.0. How can it be a good thing to use these database providers that skip over business objects?
What has finally occurred to me however is that the providers do not belong in the Data Access layer, despite the names of the providers, and despite what the magicians tell me. No, the providers belong in the Controller layer. In the case of the default SQL provider, it acts like the other layers are not even there. The default providers work as though the other layers have been erased, and it’s okay to talk directly to the database.
For small applications, it probably is okay that the providers talk directly to the database. But for a properly-architected application, let’s look at what it means that the providers are in the Controller layer. The providers “hide” the business objects from the interface layer. All the interface layer sees is the provider, and has no idea whether that provider is talking directly to a SQL database, talking directly to an Oracle database, talking to business objects, talking to web services, or talking to Felix the Cat.
In my look at Paul Wilson’s practical approach to business objects, I said that he uses a class-in-charge design where the user is represented by one User class, and the authorization role is represented by one Role class. In his WebPortal project, he uses a custom Profile provider that talks to these business objects, rather than talk directly to the database. Even better, the project’s use of an O/R Mapper means that the same provider and same business objects could use a SQL database, an Oracle database, or one of many other databases. So here is the location of Paul’s custom provider in the context of his WebPortal project. Notice that the provider is talking to the business objects, and not to the database.
Charlie does not use the same class-in-charge design used by the Wilson WebPortal. Rather, it uses a five-part Entity System. I can introduce a provider into Charlie’s Controller layer, which talks directly to the relevant Manager classes, in which case the architecture would look as follows.
What is great about the provider model—once you ignore the magicians—is that it allows the same rich server controls to work with any architecture. The Login control will work with a shallow architecture where the provider works directly with the database, or with a multi-layered architecture where the provider works with business objects (such as in the Wilson WebPortal), or with a multi-layered architecture where the provider works with manager objects (as in Charlie).
In many respects, the providers are the controllers in the popular model-view-controller pattern. The server control provides the view, the business objects provide the model, and the provider provides the controller. The providers are not true controllers, since they are not designed according to the true MVC pattern. However, they do provide the same separation of responsibilities that is the reason why the MVC pattern is so popular.
We can see then that the provider truly enhances the architectural integrity of .NET applications, and this is a very good thing. My earlier concern about providers was wholly unfounded, because I did not understand where the providers exist in the context of a layered application. I don’t think my misunderstanding is the result of me being a fool. (I may be a fool, but I don’t think it caused this misunderstanding.) Rather, I really do think .NET evanglists are magicians who focus on details (the tricks), rather than teachers who look at the bigger picture.
Now that I understand the provider model, I can see how I can maintain Charlie’s existing architecture while staying true to the design of ASP.NET version 2.0. Even better, this fleshes out Charlie’s architecture even further, since previously the Controller layer was something of a desolate landscape—there was nothing to see.
Finally, a disclaimer of sorts. This is my current understanding of the provider model, and it is an understanding brought about by my look at the Wilson WebPortal. If my understanding is wrong, or if I have misrepresented the Wilson WebPortal in my diagram above, the error is wholly mine. So if I am right, the thanks go to Paul. If I am wrong, the blame goes to me.
by Alister Jones | Next up: Sunken Ships and Pirates →
----
Post a Comment