A couple of months ago I blogged a series of posts on a small Model-View-Presenter Framework I was working on for ASP.Net (here, here, and here). At the time it was mostly wild theory bolstered with code that compiled :) I'm proud to say I now have an application using my Framework that is just about ready to go to production. woot! I got a comment on one of the older posts asking for an updated working example and felt that now was a good time to oblige.
As with any theory the actual implementation yielded some things that worked well and some things that did not work so well. One of the ideas that did not work so well was housing the View components (.ascx file) in a separate assembly, precompiling, and merging with ILMerge. These tasks were part of an AfterBuild event that would then copy the resulting output to the bin directory of the Web project. I had problems running the Web project in Debug mode because Visual Studio (with Web Application Project) insists on re-building the solution even if there have been no code changes. I ran into strong naming and version mismatch problems because certain assemblies used 1.0.0.* So the View project would build with references to other assemblies that were 1.0.0.12 then the Web project would be re-built to run in Debug causing other referenced assemblies to be rebuilt to version 1.0.0.13 and mayhem ensued. I could have turned off the automatic build revisions but use those for other purposes. The ultimate solution was to move the Views back into the Web project and be done with it. There was minimal value added in having these components in a separate assembly. The framework still supports pre-compiled Views but has the added ability to support standard .ascx Views by specifying a VirtualPath attribute when adding the component to the container.
<component id="DashboardView" service="BatchTracker.Interfaces.IDashboardView, BatchTracker.Interfaces"
type="BatchTracker.Views.DashboardView, BatchTracker.Web" virtualPath="~/Views/DashboardView.ascx"
/>
The code download includes examples of both implementations.
What has turned out to be the shining star of the Framework is the KeySearchNamingSubSystem (formerly called DynamicNamingSubsystem). This little gem has been invaluable for its ability to inject dynamic components based on runtime parameters. In a nutshell this subsystem allows the Kernel to return different service implementations based on query string parameters, allowing a single hosted application to provide interface and logic customizations to hundreds of customers without changing the base product. For the full details as well as usage notes (specifically the use of non-transient components) read the linked article.
Download the sample application here.
I'd love to hear from anyone who has experimented with my little project.