Building a Composite MVC3 Application with Ninject

Update: 05/04/2012 – Preferred alternative approach without using IoC for Plugins (

So there’s great support in Prism to building composite applications with Silverlight with the notion of Prism modules. They have a nice discovery approach for dynamically discovering modules when loading XAPs and assemblies during runtime for all the different modules your Silverlight app may need. You can load them during start-up or on demand so that you don’t have to download the entire application at one time.

When building an enterprise MVC application, I wanted to borrow some of the ideas and architecture of the Prism extensible plug and play concepts to provide the ability to build modules (areas) of your MVC application outside of your core MVC application.

For example if you had a MVC application and it’s primary role is an E-Commerce site (core site), however you have this new requirement to build a integration point to show customers all their tracking statuses for their orders. Now you have to ramp up a development team as quick as possible so that they can build out this feature, however you now find yourself giving them a full blown training and overview of your core MVC application, full source control of your entire VS Solution set which could have up to 20-30 projects in it.

Now when devs from the team compile it’s taking forever…! Here we can easily see that our MVC app’s footprint is getting to large and somewhat difficult to manage. So here is now the need to break it down into blocks that can be injected into the app during runtime so that development for these different pieces, blocks, or modules can happen in parallel with your core MVC application (loose coupling, modularity and extensibility).

My preference here is to actually use Mef since I have experience with it and the great support for MVC3 and Mef now. However, I’ve been given the opportunity to be engaged on a project that uses Ninject. With this being the situation at hand I wanted to explore and see if we could borrow the some concepts from Prism, and incorporate them using what was out of the box with Ninject. Some of these concepts include separation of concerns and loosely coupled components (modules) that can evolve independently but can be easily and seamlessly integrated into the overall application, which is also known as a composite application.

With a little bit of Googling I stumbled upon this article which was pretty much what we were looking for however it just needed to be ported from MVC2 to MVC3, use Ninject instead of Mef and just a tad bit of polishing.

So after a little bit of poking around with Ninject, I quickly found that Ninject also has a notion of Modules, NinjectModules, or classes that implement the INinjectModule interface. You can ask the Ninject Kenerl (container) to scan an assembly and it will scan for all any classes that implement INinjectModule, this can be done directly by implementing the actual interface or inheriting their out of the box NinjectModule abstract class.

So rather than starting from ground zero here, I’m going to continue with the project from my last post

Quick breakdown on the VS Solution structure:

  • MvcApplication

    This is our main MVC application which will host all the Plugins

  • MvcApplication.Plugin.Framework

    This is a C# class library where all the plugin infrastructure classes will reside

  • MvcApplicationA.Plugin

    Example PluginA

  • MvcApplicationA.Plugin

    Example PluginB

  • MvcApplicationA.Plugin

    Example PluginB

Let’s take a quick look at some of the classes in the MvcApplication.PluginFramework VS Project.

  • MyController.cs (implements IMyController)

    All controllers from plugins will need to inherit MyController, this provides some meta-data so that we can infer the correct type of a plugin Controller from our IoC that was requested.

  • MyPlugin.cs

    There will be one class in each plugin that must inherit MyPlugin, this class provides meta-data about the plugin, e.g. PluginName, AssemblyName, etc.. It also gives us the overidable Load operation where we can setup our Ninject bindings e.g. Controller and plugin bindings.

  • MyControllerFactory.cs

    We inherit the DefaultControllerFactory and override the GetControllerType method so that when a user is routed to a controller that is in a plugin, we can help the MVC runtime derive what it’s type is by scanning our IoC for registered instances for that a given Controller and return it’s type.

        public class MyControllerFactory : DefaultControllerFactory
            protected override Type GetControllerType(RequestContext requestContext, 
                string controllerName)
                var controllerType = base.GetControllerType(requestContext, controllerName);
                if (controllerType == null)
                    var controller = ServiceLocator.Current.GetAllInstances<IController>().ToList()
                    .SingleOrDefault(c => c.ControllerName == controllerName);
                    if (controller != null)
                        return controller.GetType();
                return controllerType;
  • MyRazorViewEngine (MyViewEngine.cs)

    Custom RazorViewEngine so that we can properly return Views *.cshtml (Razor) that have been copied to our Plugins directory in our main app (MvcApplication/Plugins).

  • MyWebFormEngine (MyViewEngine.cs)

    Custom WebFormViewEngine so that we can properly return MVC *.aspx (non-Razor) Views that have been copied to our Plugins directory in our main app (MvcApplication/Plugins).

  • MyPluginBootstrapper.cs and yes, I borrowed the name from Prism :p

    • Scans the “MvcApplication/Plugin” directory and loads all of our plugins
    • Register’s any custom routes from our plugins
    • Register’s our MyControllerFactory with the MVC runtime
    • Register’s our MyWebFormViewEngine with the MVC runtime
    • Register’s our MyRazorViewEngine with the MVC runtime
        public class MyPluginBootstrapper : NinjectModule
            private const string _pluginPath = "Plugins";
            private readonly string _fullPluginPath;
            private const string _defaultMaster = "Site";
            private const string _defaultRazorMaster = "_Layout";
            public MyPluginBootstrapper()
                _fullPluginPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, _pluginPath);
            public override void Load()
                var assemblies = new List<Assembly>();
                // Discover  Modules in plugin directory (e.g. site/plugins)
                foreach (var file in Directory.EnumerateFiles(_fullPluginPath, "*.Plugin.dll"))
                //  plugins discovery
                var plugins = new List<IMyPlugin>();
                foreach (IMyPlugin plugin in ServiceLocator.Current.GetAllInstances<IMyPlugin>())
                // Register ControllerFactory with site
                IControllerFactory myControllerFactory = new MyControllerFactory();
                // Setup ViewEngines
                var myWebFormViewEngine = 
                    new MyWebFormViewEngine(_pluginPath, plugins, _defaultMaster);
                var myRazorViewEngine = 
                    new MyRazorViewEngine(_pluginPath, plugins, _defaultRazorMaster);
                // Register ViewEngines with site

So what’s all required to setup an MVC plugin now?

  1. Create a regular MVC3 app project to be the plugin
  2. Assembly name must match this pattern *.Plugin.dll, yes we are using convention for this.
  3. Must have one class that inherits MyPlugin.cs

        public class PluginA : MyPlugin
            public override void Load()
  4. Setup binding for the plugin e.g. IMyPlugin -> PluginA

        public class PluginA : MyPlugin
            public override void Load()
  5. Setup bindings for any Controllers for the plugin e.g. IController -> PluginAController
        public class PluginA : MyPlugin
            public override void Load()
  6. All plugin Controllers must inherit MyController.cs
        public class PluginAController : MyController
            public ActionResult Index()
                return View();

Wrapping up, we have addressed the following concerns:

  • Loose coupling
  • Separation of concerns
  • Application modularity
  • Building our application from partitioned components
  • IoC & Dependency Injection
  • ServiceLocation with ServiceLocator and/or Ninject’s IKernel
  • Composite pattern

As requirements changed and the project matures, it will be helpful that we can change parts of the application without having these changes cascade throughout the system. Modularizing an application allow you to build application components separately (and loosely coupled) and to change whole parts of your application without affecting the rest of your code base.

Happy coding…! :)

About these ads

20 thoughts on “Building a Composite MVC3 Application with Ninject

  1. Thanks for your answer, i have other question, how i can use ninject 3 without Servicelocator, because it’s not supported in this versionof Ninject

  2. Hi. it’s a good post but i have a question how i can inject or add a plugin without restart the web server, i tried coping the dll and files but when try access to resource the page is not found, if i restart the server then the page is displayed. Thanks in advance. :)

    • I have the same issue,i tried to replace the existing plugin dll with the modified one but i can’t and gives me the message that the folder is in use. Is there any other way than to restart app pool.Thanks in advance.

  3. GetControllerType method seems to cause a performance hit, because of the inefficient search algorithm. Just saying, it could be somehow (significantly!) improved through a Dictionary or likewise.

    • Hi estorski, could you be so kind to share your implementation? If it perf improvement, I may want to include your contribution to the blog post.

  4. It’s possible to add an area in plugin???

    How can i register it???

    I mean to add an admin area for each plugin … is it possible??

    • I think it depends. With this IoC approach you have more control over the plugins and the structure of your application. You can use many features of the IoC’s like policy injection and interception. Unlike Long Le, I don’t see the dependancy on an IoC as a negative thing. In real world application you need an IoC for many reasons. So why not use that for composition of the Area’s, too?

      I think that this approach give much more control over your application and the added plugins. But it’s just me :-)

      It would be even better if there was a way to add plugins without restart the application.

      By the way, really good job. Readable and very nice to follow post.

  5. i have some question:
    1) can i have two controller in different plug in with same name?
    2)can i use custom membership provider with this method?


    • Luigi,

      1. No, all controller names have to be unique, this is a MVC rule, which is favoring convention over configuration.

      2. Yes, you should be able to use any type of membership provider, I’ve used the SimpleMembershipProvider already.

  6. This rocks, great tutorial man, exactly what I need. Is there any license involved in using this code? I want to use it in what will be a commercial app, and don’t want to tread on anyones toes so to speak.

    • Hi Will, no there is no licensing involve, your golden. :) If you could put the blog url above where you are using this code in the comments that would be awesome.

    • Oh of course, I’ll credit you and the blog post no problems.. in all classes referenced.. it’s just awesome that dedicated coders like you are providing such good solutions for free.. I’d honestly never thought of using Ninject like this, but it’s an amazingly elegant approach, and seems to minimize any Reflection needed.. many thanks, and have a great New Year :D

  7. Hi, can i also ask a question. How can i use partials from plugins in main MVC solution. For ex. in About view how can i use @Html.Action(“PlaginA”,”Index”)? when I try to do this it returns an error Server Error in ‘/’ Application.
    The controller for path ‘/Home/About’ was not found or does not implement IController.

  8. hi,
    this is really great article, but i have one question, how could we install plugins by user?
    what i mean is after the project is compiled, and uploaded online, later i develop a plugin and copy it to the plugins directory, how can i install it or make the application aware of it without recycling or recompiling the app?

    • hi devmondo,

      You could create a view for a user/developer to upload there project (.zip) programmatically decompress it and copy it to the right folder. Post the copy, you could use the Ninject Kernel to scan the assemblies so that all the Controllers for the plugin are registered with Ninject’s IoC container, in theory this should not require a recycle.

      I would also highly recommend going with this architecture to build a composite (pluggable) MVC application:

    • Thanks a lot man for reply, and i read your other article which is brilliant too, but i think MVC main application wont see the routes, modelbinders, etc. because i have tried to do what you suggested and used ninject Kernal and it loaded fine but not routes, Modelbinders, etc….

      am i missing anything ?

Please Leave a Reply or Tweet me @LeLong37...!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s