Implementing MEF with ASP.NET MVC?

Question

I am trying to find out if anyone has any experience or ideas of using MEF (Managed Extensible Framework (Microsoft's new plugin framework) with ASP.NET MVC. I need to create a standard ASP.NET MVC, which I have. But I need to offer additional functionality i.e. Views and Controllers, etc, depending on if I add a plugin. It doesn't need to be dynamically compiled i.e. source code... but a DLL that i put into the system..

Is there any way to dynamically load a DLL when the app starts, and then MERGE a VIEWS and CONTROLLERS with the main system? I don't know if i am on the right track here.

Then, I suppose in the "STANDARD" views that come with the app, I can use an "IF THEN" to find out if a plugin is loaded and MERGE in a user control.

Well, I'm talking out loud here, but I think you understand what I am getting at.

Any ideas?

Answer 1

any luck with that? I was reading this and think that's what you're looking for.
I have exactly zero xp with MEF, but it looks promising. I hope I can scrape some hours of free time together at home to experiment with that. It would be ultra usefull to create some kind of modularized MVC "framework" that way.

As for the current project I'm working on, I have the following problem: Multiple sites with the same views, only other CSS files. Currently I have to duplicate the views resulting in a maintaince problem.
I'm hoping I can put these views in a central place using MEF.

Answer 2

We're using tons of MEF in ASP.NET MVC, though most of it sits at a level below the controller level, as in our lower level modules use MEF plugins for checking permissions and validating data.

However, we also use a more composable approach to our controllers too. Views are more tricky, but we actually completely eliminated the use of regular ASP.NET MVC views and store our Razor views in snippets in a database. Our controllers then ask a template engine for a view at runtime and render ContentResult to the response instead of returning View("Viewname"), etc.

Our MEF plugins all carry identifier properties that let us do a cascading override at runtime to figure out which plugin/class should be used for a given purpose. The easiest example to demonstrate would be if you think about an app that has a common base, but is deployed to 50+ implementations that each have the option to override the core functionality.

So, you might have something like an IUserController that includes methods for "Login", "Logout", etc.

In addition to that actual functionality, we'd add a read-only GUID property to the interface called "SiteId". Each implementation would then hard-code the SiteId it's intended for. For the "default" implementation in the core code, it would return "Guid.Empty".

Then, when we invoke MEF and go looking for which implementation of IUserController to use, we'd do an ImportMany of all of them into a List and then use LINQ to query the properties to figure out which one to use:

var _currentUserController = _availableUserControllers.FirstOrDefault(
  c=>c.SiteId == AppSettings.SiteId);
if(_currentUserController == null){
    //There is no site-specific override
    _currentUserController = _availableUserControllers.FirstOrDefault(
      c=>c.SiteId == Guid.Empty);
}

To do this with controllers, your best bet is to look at some of the implementations of MEF-based controller factories out there on the web.

However, like I said, we do nearly all of this at a level that's lower and have our modules or the controllers do this kind of lookup to determine which plugins to run.

Answer 3

Check this :

http://www.fidelitydesign.net/?p=104

Modular ASP.NET MVC using the Managed Extensibility Framework (MEF), Part One by Matthew Abbott.

Answer 4

This is a wild guess. You could overwrite the default controller factory with one that uses MEF to discover IControllers. Since Views are discovered by convention, you shouldn't have to worry about them.