Dec 24, 2008 at 1:47 AM
Edited Dec 24, 2008 at 1:57 AM
I've integrated the MEFContrib's MEFContrib.Library.Web library into the Community Starter Kit (now called the Community Advanced Starter Kit -
CASK). MEF will handle all externally loaded modules while Unity handles DI for all Pages/User controls.
I'd be interested in any feedback/Code review comments from the Gurus in the manner I addressed an issue I ran into (I post a question at the end of this message thread). Also blogged about
The dynamic nature of CASK (data driven website) is such that I ran into a "Chicken-before-the-egg" scenario. Under normal situations the ASP.NET page's content is composed
after Page_Init(), this permits dynamically loaded controls to be loaded/composed as well. This is problematic for CASK because during the Page_Init() the following command is executed:
(Control)Activator.CreateInstance(BuildManager.GetType( class name)) ;
Which requires that the module be loaded or it will crash. I updated the HttpModule to Compose prior to the page's Page_Init() to handle this which effectively will allow all
externally uploaded modules to be available to the Page_Init and configurable via the Module Manager (refactor in progress for MEF).
The Unity Container, also available at Page_Init(), will perform post init processing as currently designed by the MEFContrib library effectively providing DI to all pages and user controls. Currently *every* control is being "BuildUp" which is not
very efficient; I'm looking at creating a policy to narrow the processing down to applicable classes.
Would a post init - secondary Compose() be a bad practice or cause issues?