In Part 3 we will look at how to utilize Ninject’s features within our application, along with what kind of functionality can be delivered. At this point, let’s revisit our goals from Part #1:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

Hypothetically, let our application be a standard transactional system, with header records at the top level and child records below it. Furthermore, let it be an order entry system, so we will need to know about quantities, prices, have subtotals, etc. Our standard interface can be for Work Orders, and look something like the following:

WorkOrders.aspx:

We have some header information (Work Order #, etc.) and child records, and the ability to interact with the application to modify child records and add new ones. At this point, a large customer likes what you’ve done so far and wants to use your application to manage their shop. But instead of work orders, they need to use Purchase Orders. You need to make some major modifications without affecting your existing functionality, so you create a new page and use Ninject to inject the right functionality into the application. Because we implemented Goal #2 in Part 2, we merely need to modify our source repository to provide the PurchaseOrders.aspx page instead of WorkOrders.aspx.

From CompanyConfigProvider.cs:

                // construct our list of Views to be used throughout the application
                // for Goals #2 and #3
                foreach (KeyValuePair<string, string> item in r.getViews())
                {
                    cc.Views.Add(item.Key, item.Value);
                }

In addition, because these Purchase Orders are between your client and their own customers and not intra-company Work Orders, there are potential tax implications — as such, you will need to introduce a method of keeping track of tax when necessary. It will utilize the existing Purchase Orders functionality, but will need to augment it — the perfect usage of partial views.

TotalNoTax.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<p>Non-Profit Tax Code: <input type="text" name="taxinfo" /></p>

TotalWithTax.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<p>Tax Amount: <input type="text" id="taxinfo" name="taxinfo" /></p>
<script type="text/javascript">
    function updateTax() {
        var qty = parseFloat($("#quantity").val());
        $("#taxinfo").val(qty * 150 * .06);
    }

    $(document).ready(function() {
        $("#quantity").blur(updateTax);
        $("#itemType").change(updateTax);
    });
</script>

Very simply, we will use jQuery to manage a new form element that will include tax when necessary. Let’s start putting it all together. First, let’s take a look at our controller:

From OrdersController.cs:

using {etc}

namespace MultiTenantNinject.Controllers
{
    [HandleError]
    [ProvideCompanyConfig]
    public class OrdersController : Controller
    {

As you can see, we inherit from Controller like normal and utilize our ProvideCompanyConfig attribute so that we can be assured we have access to our company config upon rendering. Let’s take a look at an Action:

        public ActionResult Index()
        {
            ViewResult v = View(_companyConfig.Views["Order Management"]);

			// add view data items for the header and children;

			// add item to be used for determining if it's a taxable or non-taxable transaction:
			v.ViewData.add("taxState",repository.TaxState);

            return v;

        }

The first step in rendering the View to the user is ensuring we have an “Order Management” entry in our Views collection that establishes what type of major functionality to use. Our repository would load the config file with a text entry like “WorkOrders” or “PurchaseOrders” to correspond with “WorkOrders.aspx” or “PurchaseOrders.aspx”, respectively. We can set our ViewData at this point, perhaps using a service object (which we will explore soon) and then return the view. At this point, we have a solid understanding of achieving Goal #2, so let’s take a look at the few lines necessary to achieve Goal #3:

From PurchaseOrders.aspx:

    <% var configSettings = (MultiTenantNinject.Models.ICompanyConfig)ViewData["companyConfigSettings"];  %>
	<h3>Purchase Orders</h3>
	... etc ...
    <p><% Html.RenderPartial(configSettings.Views[string.Format("Taxes_{0}",ViewData["taxState"])]); %>

By utilzing the correct entry in our repository for the user’s state, we can provide the correct tax functionality. If the company’s location was in Florida, the repository could provide “TotalWithTax” for the “Taxes_FL” binding, and “TotalNoTax” for the other states. Obviously we can take it up a level of abstraction and determine whether or not this transaction is taxable in the controller or service object, but this serves as an adequate example of Goal #3. Lastly, let’s take a look at our solution for Goal #1 — it’s all well and good when we can provide custom front-end functionality for our users, but at some point we will need to implement logic and manipulate data. Let’s revisit the module where we inject our services:

From OrderModule.cs:

        public override void Load()
        {
            // use reflection to bind a list of types (from our Config's "Bindings" collection)
            // to be used when called upon during injection
            string serviceLocationPrefix = "MultiTenantNinject.Services.";
            foreach (KeyValuePair<string,string> item in _config.Bindings)
            {
                Bind(Type.GetType(serviceLocationPrefix + item.Key)).To(Type.GetType(serviceLocationPrefix + item.Value));
            }
        }

We will need to provide an interface and an implementation for our service(s). Firstly, the interface:

IOrderService.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Web.Mvc;

namespace MultiTenantNinject.Services
{
    public interface IOrderService
    {
        string Process(ViewDataDictionary viewdata);
        DataTable Orders { get; set; }
    }
}

and one of the implementations:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Web.Mvc;

namespace MultiTenantNinject.Services
{
    public class VideoCardOrderService: IOrderService
    {

        #region IService Members

        public string Process(ViewDataDictionary viewdata)
        {
            // here we do transactions pertaining to video cards
            return "Thanks for buying a video card!";
        }

        #region Orders
        private DataTable _Orders;
        public DataTable Orders
        {
            get
            {
                return _Orders;
            }
            set
            {
                if (_Orders == value) return;
                _Orders = value;
            }
        }
        #endregion

        #endregion

    }
}

Service objects can perform most of the functionality of your application, and do not need to be gone over in great detail, as they are as varied as anything else can be. Suffice it to say that it’s a standard interface/implementation pattern of development. Ninject allows you to set it up for injection, as we did in Part 2, so that whenever you call a particular interface for this user a particular implementation is used. “VideoCardOrderService” could easily be “MotherboardOrderService” or “CarOrderService”:

From OrdersController.cs:

        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Save()
        {
            _orderService.Process(ViewData);
            return new RedirectResult("Index");
        }

Our controller, in the end, is completely agnostic of our major functionality, our minor (partial view) functionality, and our domain logic:

OrdersController.cs:

using {etc}
using Ninject;

namespace MultiTenantNinject.Controllers
{
    [HandleError]
    [ProvideCompanyConfig]
    public class OrdersController : Controller
    {
        ICompanyConfig _companyConfig;
        IOrderService _orderService;

        public OrdersController(ICompanyConfig pCompanyConfig, IOrderService pOrderService)
        {
            _companyConfig = pCompanyConfig;
            _orderService = pOrderService;
        }

        public OrdersController()
        {
        }

        public ActionResult Index()
        {
            ViewResult v = View(_companyConfig.Views["Order Management"]);

			// add view data items for the header and children;

			// add item to be used for determining if it's a taxable or non-taxable transaction:
			v.ViewData.add("taxState",repository.TaxState);

            return v;
        }

        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult Save()
        {
            _orderService.Process(ViewData);
            return new RedirectResult("Index");
        }
    }
}

Thus, the conclusion to our series about utilizing dependency injection within ASP.Net MVC to enhance a Multi-Tenant Architecture. We can provide service objects without our controller (or anything else) performing logic switches, we can provide major changes to functionality without creating a new codebase, and we can provide in-place customizations truly in-place. In addition, we’ve created our application such that we can utilize any kind of data layer or repository and we can utilize testing frameworks to test our code without having to rewrite anything. And lastly, although it’s taken a moderate level of effort to get to this point, we can be secure in the knowledge that additional changes can be implemented without affecting existing functionality, and we can easily swap out functionality when the situation arises with very little additional effort.

To start off with, let’s talk about using Ninject with ASP.Net MVC. You’ll need to download the appropriate Ninject version for your .NET framework. Our example will use Ninject 2.0 with ASP.Net MVC 1. Download Ninject from the homepage at http://ninject.org/ and visit the dojo and github to learn the basics. Ninject will manage our controllers for us (it needs to, so it can monitor for injection points) and so will need to be tightly integrated into our application. For starters, we’re going to need to change our global.asax.cs file. Take a look:

Global.asax.cs:

using System;
using System.Collections.Generic;
using System.Reflection;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Ninject.Web.Mvc;
using Ninject;
using Ninject.Modules;
using MultiTenantNinject.Controllers.Components;
using MultiTenantNinject.Models;

namespace MultiTenantNinject
{
  // Inherit from NinjectHttpApplication instead of HttpApplication
  public class MvcApplication : NinjectHttpApplication
  {
    public static void RegisterRoutes(RouteCollection routes)
    {
      routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

      // hack for visual studio's web server
      routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.ico(/.*)?" });

      routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = "" } // Parameter defaults
      );

    }

    // we use OnApplicationStarted, because Ninject is using Application_Started
    protected override void OnApplicationStarted()
    {
      // no big surprise here -- register our routes.
      RegisterRoutes(RouteTable.Routes);
      // register every controller in our application for injection
      RegisterAllControllersIn(Assembly.GetExecutingAssembly());
    }

    // this is called automatically from within the Ninject framework
    protected override IKernel CreateKernel()
    {
      // create a Kernel to manage injections.
      // have the Kernel process our "SetupModule" class
      IKernel k = new StandardKernel(new SetupModule());
      // have the Kernel process our "ConfigModule" class
      k.Load(new ConfigModule());
      // have the Kernel process our "OrderModule class
      // pass an instance of our company config that our ConfigModule calls for
      k.Load(new OrderModule(k.Get<ICompanyConfig>()));
      return k;
    }
  }
}

You can see how the CreateKernel() method loads a number of Modules to manage our Dependency Injection. Let’s take a look at these modules. The first module to investigate will provide bindings for our .NET MVC dependencies.

SetupModule.cs:

using {etc}
using Ninject;
using Ninject.Modules;
using Ninject.Web.Mvc;

namespace MultiTenantNinject.Controllers.Components
{
    // inherit from NinjectModule
    public class SetupModule : NinjectModule
    {
        // NinjectModule is an implementation of the Strategy design pattern and must implement "Load()"
        public override void Load()
        {
            // Let's inject .NET MVC framework dependencies, wow!
            Bind<IFormsAuthentication>()
                .To<FormsAuthenticationService>();
            Bind<IMembershipService>()
                .To<AccountMembershipService>();
            Bind<MembershipProvider>()
                .ToMethod(ctx => Membership.Provider);
        }
    }
}

Our next module will bind the heart of our Multi Tenant Architecture, the “Company Config”. This configuration object will be lightweight, cached server-side (ideally once for each company) and will be available during most operations of the page lifecycle.

ICompanyConfig.cs:

using {etc}

namespace MultiTenantNinject.Models
{
    public interface ICompanyConfig
    {
        // Task #1 -- provide service objects
        Dictionary<string, string> Bindings { get; set; }
        // Task #2 & #3 -- provide views and partial views
        Dictionary<string, string> Views { get; set; }

        String CompanyName { get; set; }

    }
}

ConfigModule.cs:

using {etc}

namespace MultiTenantNinject.Controllers.Components
{
    public class ConfigModule : NinjectModule
    {
        public override void Load()
        {
            // Ninject.Activation.Provider is a factory object.
            CompanyConfigProvider Provider = new CompanyConfigProvider(WebConfigurationManager.AppSettings);

            // Bind our service (ICompanyConfig) to its implementation using the
            // aforementioned Provider.  Bind it so that each request uses the same
            // instance of the service.
            Bind<ICompanyConfig>()
                .ToProvider(Provider)
                .InRequestScope();

        }
    }
}

Our next module will control the functionality for our example customizations revolving around Purchase Orders. In practice we could have multiple modules, perhaps one for each functional area of our application, but our single module will serve our purposes here:

OrderModule.cs:

using {etc}

namespace MultiTenantNinject.Controllers.Components
{
    public class OrderModule : NinjectModule
    {
        private readonly ICompanyConfig _config;

        // We see our first "Inject" attribute.
        // Here we will take an instance of our company config
        // and later use it to bind our application services
        [Inject]
        public OrderModule(ICompanyConfig companyConfig)
        {
            _config = companyConfig;
        }

        public override void Load()
        {
            // use reflection to bind a list of types (from our Config's "Bindings" collection)
            // to be used when called upon during injection
            string serviceLocationPrefix = "MultiTenantNinject.Services.";
            foreach (KeyValuePair<string,string> item in _config.Bindings)
            {
                Bind(Type.GetType(serviceLocationPrefix + item.Key)).To(Type.GetType(serviceLocationPrefix + item.Value));
            }
        }
    }
}

Let’s briefly revisit our goals from Part #1:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

At this point we can see the pattern unfolding. We use our Modules to dictate to the Kernel what strategies to use when binding implementations to our services. We can use reflection, we can use strings and types, and we can use Providers inside of our Modules during binding. We will be coming back to OrderModule.cs, as that is part of our implementation for Goal #1. Let us take a look now at our Provider from our ConfigModule:

CompanyConfigProvider.cs:

using {etc}
using Ninject.Activation;

namespace MultiTenantNinject.Models
{
    // inherit from Ninject.Activation.Provider
    public class CompanyConfigProvider: Provider<CompanyConfig>
    {
        // these settings are provided by our web.config in this example
        public CompanyConfigProvider(NameValueCollection settings)
        {
            Settings = settings;
        }

        protected NameValueCollection Settings { get; set; }

        // build and return an instance of our CompanyConfig using the specific context
        // IProvider is a Factory that will have its CreateInstance() method called
        // the first time that a CompanyConfig is injected
        protected override CompanyConfig CreateInstance(IContext context)
        {
            // use a caching mechanism to store our company config.  we cannot
            // cache in the Application cache because we have a Multi Tenant Application.
            // we can use Session in a pinch, although depending on your application's traffic,
            // you might need to use something else
            System.Web.SessionState.HttpSessionState Session = HttpContext.Current.Session;
            CompanyConfig cc = null;

            // if we don't have a cached company config:
            if (Session == null || Session["cc"] == null)
            {
                cc = new CompanyConfig();
                // our repository is extremely unsophisticated, but you should
                // get the idea of how this works.  it may very well be passed in
                // via constructor injection
                MultiTenantNinject.Models.Repository r = new Repository();

                // construct our list of Views to be used throughout the application
                // for Goals #2 and #3
                foreach (KeyValuePair<string, string> item in r.getViews())
                {
                    cc.Views.Add(item.Key, item.Value);
                }
                // construct our list of service bindings to be used throughout the application
                // for Goal #1 (previously seen in OrderModule.cs
                foreach (KeyValuePair<string, string> item in r.getBindings())
                {
                    cc.Bindings.Add(item.Key, item.Value);
                }
                // if we can cache our company config:
                if (Session != null && Session["cc"] == null)
                {
                    Session["cc"] = cc;
                }
                // set company name (normally would be from the repository)
                cc.CompanyName = "Widgets, Inc.";
            }
            else  // we have a previously cached company config
            {
                cc = (CompanyConfig)Session["cc"];
            }

            return cc;
        }
    }
}

To make our lives a little easier and yet more structured, let’s create an ActionFilterAttribute to inject our CompanyConfig into our Views:

From ProvideCompanyConfigAttribute:

    public class ProvideCompanyConfigAttribute : ActionFilterAttribute
    {
        [Inject]
        public ICompanyConfig Settings { get; set; }

        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            filterContext.Controller.ViewData.Add("companyConfigSettings", Settings);
        }
    }

We use Ninject’s “Inject” attribute to provide the CompanyConfig to our Attribute, and then inject the config into the controller as a matter of course.

At this point we’ve seen how Ninject positions itself within our application (a controller factory and application superclass) and how we can use Ninject’s modularity to manage our bindings. We’ve touched upon Goals #1, 2, and 3, and can see it taking shape before us. We have a company configuration that encapsulates the customizations for the currently logged in user and provides the customized bindings and views for that logged in user. We have basically everything we need to begin working with our customized functionality.

To get this far we have made the following assumptions:

1. Your repository works.
2. You have an ASP.Net MVC application in otherwise working order.
3. You have downloaded and referenced the Ninject libraries.

In Part 3 we will look at our application controllers and views, and then explore what we can do to provide customized functionality to our users.

1. Your users all log into a single codebase. It might be load balanced, cached, the whole nine yards, but everybody is on the same build and accesses the same data.
2. Your users log into multiple codebases and/or multiple databases. Perhaps you have some high-powered customers who want custom functionality, and so you forked your codebase and created them their own functionality. Most likely, you can update your customer’s builds independently of one another.
3. Your users all log into a single codebase, but you use flags, connection strings, config files, etc., to logically separate out your users from one another. Your high-powered customers see their custom functionality, but it’s part of the main codebase and you are able to update your application in one fell swoop.

We’re going to talk more about option #3 — the Multi-Tenant Architecture. There is PLENTY of reading material out there for you to learn more about multi-tenancy. Suffice it to say that it allows you to satisfy multiple sets of requirements for your multiple customers via one codebase, and your customers, most likely, are logically separate in the database(i.e. they use one schema and one top-level data store) instead of physically separate.

In the past, (and present, for novice developers), it was a usual practice to utililze config files, database flags, etc., to turn on and off functionality. Your code may have looked something like:

<% if (showThisFunctionality) %>
<-- this widget is shown -->;
<% else %>;
<-- this other widget is shown -->
<% end if %>

Fig 1: Classic ASP

By utilizing a dependency injection framework you can provide features to your users, based on configuration and setup, without having to use logic switches inside of your application. This is above and beyond the existing benefits of using a dependency injection framework, which is not the scope of this essay but can be enumerated here, for instance. Our example will use Ninject and ASP.NET MVC, although you could use any DI and application frameworks.

Our challenge for this example will be to:

1. dynamically set which service object(s) we are using to perform our application logic
2. dynamically set which view we are returning
3. dynamically set which partial views we are using

Our example will utilize dependency injection to provide order fulfillment functionality for our customers. For goal #1, we will use Ninject's MVC integration to provide service objects for our controllers. Once Ninject is wired up, we can have our service objects perform our application logic against our Model, and as a matter of fact, Behavioral design patterns are a good fit here. Goal #2 is achievable fairly easily with ASP.Net MVC. Setting which view you're returning via any MVC framework is often a very simple operation and comes down to returning a string variable which represents the view in question. For ASP.NET MVC we can 'returnView("viewName")' where "viewName" is the name of the view we wish to return. There is also the obvious "return View(viewNameVariable)" override. Our example will use a configuration object to set which view is being called. Accomplishing goal #3 can be thought of as an extension of #2, but "finer grained". Where you have general and reusable functionality within your view, your partial views allow you to have specific customizations exposed to your user in a consistent fashion.

In Part 2 we will investigate both integrating Ninject with ASP.Net MVC as well as what shape our framework will take. In Part 3 we will finish up our framework architecture and explore how to use it to provide features to our users.