There is a way however, to intercept the message before it is returned to the front-end and log the error automatically the way we are used to with Elmah.

First we set up an ErrorHandlerFilter class which will override the default error stream message ( {“Message”:”There was an error processing the request.”, “StackTrace”:””, “ExceptionType”:””})} with a more meaningful error message with details.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.IO;

   4: using System.Linq;

   5: using System.Text;

   6:  

   7: namespace Namespace.ElmahExtension

   8: {

   9:     public class ErrorHandlerFilter : Stream

  10:     {

  11:  

  12:         private readonly Stream _responseFilter;

  13:  

  14:         public List<byte> OriginalBytesWritten { get; private set; }

  15:  

  16:         private const string Content =

  17:           "{\"Message\":\"There was an error processing the request.\"" +

  18:           ",\"StackTrace\":\"\",\"ExceptionType\":\"\"}";

  19:  

  20:         public ErrorHandlerFilter(Stream responseFilter)

  21:         {

  22:             _responseFilter = responseFilter;

  23:             OriginalBytesWritten = new List<byte>();

  24:         }

  25:  

  26:         public override void Flush()

  27:         {

  28:             byte[] bytes = Encoding.UTF8.GetBytes(Content);

  29:             _responseFilter.Write(bytes, 0, bytes.Length);

  30:             _responseFilter.Flush();

  31:         }

  32:  

  33:         public override long Seek(long offset, SeekOrigin origin)

  34:         {

  35:             return _responseFilter.Seek(offset, origin);

  36:         }

  37:  

  38:         public override void SetLength(long value)

  39:         {

  40:             _responseFilter.SetLength(value);

  41:         }

  42:  

  43:         public override int Read(byte[] buffer, int offset, int count)

  44:         {

  45:             return _responseFilter.Read(buffer, offset, count);

  46:         }

  47:  

  48:         public override void Write(byte[] buffer, int offset, int count)

  49:         {

  50:             for (int i = offset; i < offset + count; i++)

  51:             {

  52:                 OriginalBytesWritten.Add(buffer[i]);

  53:             }

  54:         }

  55:  

  56:         public override bool CanRead

  57:         {

  58:             get { return _responseFilter.CanRead; }

  59:         }

  60:  

  61:         public override bool CanSeek

  62:         {

  63:             get { return _responseFilter.CanSeek; }

  64:         }

  65:  

  66:         public override bool CanWrite

  67:         {

  68:             get { return _responseFilter.CanWrite; }

  69:         }

  70:  

  71:         public override long Length

  72:         {

  73:             get { return _responseFilter.Length; }

  74:         }

  75:  

  76:         public override long Position

  77:         {

  78:             get { return _responseFilter.Position; }

  79:             set { _responseFilter.Position = value; }

  80:         }

  81:     }

  82: }

Now, we’re going to need to set up a class that implements IHttpModule.  which we’ll use to intercept the message being passed after the Request and EndRequest handlers execute.

   1: using System;

   2: using System.Diagnostics;

   3: using System.IO;

   4: using System.Text;

   5: using System.Web;

   6: using System.Web.Services.Protocols;

   7: using Elmah;

   8:  

   9: namespace Namespace.ElmahExtension

  10: {

  11:     public class ElmahExtension : IHttpModule

  12:     {

  13:         private HttpApplication _application;

  14:  

  15:         public void Dispose()

  16:         {

  17:         }

  18:  

  19:         public void Init(HttpApplication context)

  20:         {

  21:             _application = context;

  22:             _application.PostRequestHandlerExecute += OnPostRequestHandlerExecute;

  23:             _application.EndRequest += OnEndRequest;

  24:         }

  25:  

  26:         private void OnPostRequestHandlerExecute(object sender, EventArgs e)

  27:         {

  28:             var context = sender as HttpApplication;

  29:             if(context != null && (context.Request.Path.Contains(".asmx") && (context.Response.StatusCode >= 400 && context.Response.StatusCode < 600)))

  30:             {

  31:                 context.Response.Filter = new ErrorHandlerFilter(context.Response.Filter);

  32:             }

  33:         }

  34:  

  35:         static void OnEndRequest(object sender, EventArgs e) 

  36:         {

  37:             var context = (HttpApplication)sender;

  38:             var errorHandlerFilter = context.Response.Filter as ErrorHandlerFilter;

  39:  

  40:             if (errorHandlerFilter == null)

  41:             {

  42:                 return;

  43:             }

  44:  

  45:             var originalContent = Encoding.UTF8.GetString(errorHandlerFilter.OriginalBytesWritten.ToArray());

  46:             ErrorLog.GetDefault(context.Context).Log(new Error(new Exception(originalContent)));

  47:         }

  48:     }

  49:  

  50: }

Notice in the OnPostRequestHandlerExecute function we’re intercepting any request that comes from a Webservice (.asmx page) and has a status code of greater than 400 (All error code types).  At his point we want to set the ErrorHandelerFilter to the current Response.Filter value.

Now in the OnEndRequest function we want to get the current context and set the error handler based on the filter which should now be persisting the values we set in the previous function.  Once we have the error values all we have to do is call the Elmah manual logging API and log the exception.

The final piece you have to do is set up the webConfig to recognize and use your IHttpModule code. n In your config file navigate down to System.Web >> HttpModules and fill in the attribute accordingly.

   1: <system.web>

   2:     <httpModules>    

   3:       <add name="ElmahExtension" type="Namespace.ElmahExtension.ElmahExtension"/>

   4:     </httpModules>

   5: </system.web>

Once you compile and run, any errors encountered in your web services should now be logged by Elmah just like any others.

Thanks to Reddy Kadasani, Mike Gerety and Dylan Barrett for their contributions to this solution.

This kind of solution can be applied to several situations such as complex data processing, dynamic loading, or combining them all into a seamless form submission process that would clear the form on post backs.

We can accomplish this process simply by grabbing an event, such as a button click, and collecting all the required information using jQuery.  Next using a JSON call, we can pass all the parameters to the web service and execute our code from there.

Here, I’ll start with a simple .aspx page with jquery, a textbox, and link that will be used to call the web service.

   1: <%@ Master Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="ThisPage.cs" Inherits="ThisSolution.ThisProject.ThisFolder" %>

   2:  

   3: <asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" runat="server">

   4:     <script src="/Scripts/jquery-1.4.1.min.js" type="text/javascript"/>

   5: </asp:Content>

   6:  

   7: <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

   8:     <asp:TextBox ID=”textBox” TextMode="MultiLine" runat="server"></asp:TextBox>

   9:     <a href="#" class="buttonClass"> Save </a>

  10:     <asp:Label ID=”successLabel” runat="server"></asp:Label>

  11: </asp:Content>

Next, you will need to establish your web service and create an .asmx file.  There are a couple of important things to note here. Line 5 will be by default commented out.  So in order for us to make our JSON call we’re going to need this uncommented.  Also, notice I’m returning a string.  For the purposes of this demo I am going to return a string to the UI and display a message, but you can return any kind of object that can be serialized down to a primitive data type.

   1: [WebService(Namespace = "http://tempuri.org/")]

   2: [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

   3: [System.ComponentModel.ToolboxItem(false)]

   4: // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. 

   5: [System.Web.Script.Services.ScriptService]

   6: public class wService : System.Web.Services.WebService

   7: {

   8:     [WebMethod()]

   9:     [ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]

  10:     public string UpdateComment(string textBoxText)

  11:     {

  12:         var success = Service.CallToDb(textBoxText);

  13:  

  14:         if(success)

  15:         {

  16:             return "Call to Database using text was successful";

  17:         }

  18:         else 

  19:         {

  20:             return "Call to Database using text was not successful";

  21:         }    

  22:     }           

  23: }

I use a jQuery selector to pick up on the mouse click of the link and gather our data into an javascript object.  Note that when passing parameters through this object you have to name them the same way as you do in the parameter declaration of the web service.

When setting up the call to the service you’re going to want to remember to call the “JSON.stringify” function on your data object so that it serializes properly and that your contentType as well as dataType are configured properly as well.

   1: <script type='text/javascript>

   2:     $('.buttonClass').live('click', function(){

   3:         var text = $('#textBox').text();

   4:         var data = new Object();

   5:         data.textBoxText = text;

   6:  

   7:         $.ajax({

   8:             type: "POST",

   9:             url: "/Ajax/WbServcie.asmx/UpdateComment",

  10:             data: JSON.stringify(data),

  11:             contentType: "application/json; charset=utf-8",

  12:             dataType: "json",

  13:             success: function(msg){

  14:                 $('#successLabel').val(msg);

  15:             },

  16:             error: function(msg){

  17:                 alert('Something, somewhere, has gone terribly wrong');

  18:                 return false;

  19:             }

  20:         });    

  21: </script>

Once you get a response from the service, you can set any of your data that is returned.  In this case, we’re returning a string indicating the call to the database was successful and will set a label on the page to show that.

And that’s it.  With just a few simple configurations we have a quick call back to the server without having to run an expensive post back.

Many companies have followed models put forth by sites such as www.amazon.com, with their widely known desktop interface for purchasing products. When the mobile markets started to pick up they developed a mobile site that operates in much the same way, but offers a friendlier user experience for those viewing it on a smartphone screen. This move to a mobile intuitive platform can generate an increase in traffic and user engagement with the site by up to 85%.

A push to a mobile platform such as this doesn’t have to be expensive either. On a recent client engagement, I developed a mobile version of their desktop website that was established prior to my arrival. While building the mobile pages I was able to reuse a lot of the code behind, but with some simple device detection logic I finished the project a lot sooner and cheaper than if I had to develop a new site form square one.

Currently, 1 in 4 mobile devices are smartphones, and with the relatively low incremental development cost, and the prospect that mobile device users will overtake the number of desktop casual browsers by 2014, the importance of developing mobile friendly sites in tandem with their desktop versions will increase and will be a great benefit to any client with public facing websites.

Mobile usage statistics courtesy of KissMetrics

This solution cannot work if you want to compress and use the file in memory without writing to disk.  An example of this could be on a server where you don’t particularly want to have random processes writing to and reading files. 

Listed below is a solution we came up with for compressing a file in memory. We used an open source library SharpZipLib from sharpDevelop.net.  There are other good options out there that could also be used.  We found that using this library offered the most intuitive solution to creating the archive file.

The result will be a Stream which can be used to send the compressed data to an FTP Site, attach and send in an email, or if you don’t have any restrictions, write to a local folder.

First we will declare a method that reads in a string of data, initialize a MemoryStream and ZipOutputStram.

using ICSharpZipCode.SharpZipLib.Zip;

…

public static byte[] CompressFile(string fileContents)
        {
            //Initialize memory stream the compressed data will be written to
            using (MemoryStream outMs = new MemoryStream())
            {
                using (ZipOutputStream zipOut = new ZipOutputStream(outMs))
                {
                    ZipEntry ze = new ZipEntry("OriginalMessage.txt");
                    ze.CompressionMethod = CompressionMethod.Deflated;
                    zipOut.PutNextEntry(ze);

                    //Write the string to the to buffer that will be fed into the ZipStream
                    byte[] byteArray = new byte[fileContents.Length];
                    int index = 0;
                    foreach (char fileChar in fileContents)
                    {
                        byteArray[index] = (byte)fileChar;
                        index++;
                    }

                    //Write the compressed data to the outMs memory stream
                    zipOut.Write(byteArray, 0, byteArray.Length);
                    zipOut.Finish();
                }
                return outMs.ToArray();
            }
        }

This isn’t much different from other methods out there.  Notice the data is written to a byte array and given to the ZipOutputStream’s compression call which in turn writes the compressed data to a memory stream.  The difference here is when we return an array of the MemoryStream.

The reason we return the array and not the memory stream is because once we exit the scope of the method we will lose the Memory Stream and the data contents.

Once this compression has been done the calling class should then use some sort of stream to finish the desired functionality.  Below is an example of this by attaching the compressed data to an email.

public static void SendTestEmailWithAttachment(byte[] message)
       {
           try
           {
              var emailClient = new SmtpClient("mail.client.com", 25)
                                 {
                                     Credentials = new NetworkCredential("relay.client.com", "")
                                 };

              var sendFrom = new MailAddress("karl.schwirz@tallan.com");
              var sendTo = new MailAddress("karl.schwirz@tallan.com");

              var myMessage = new MailMessage(sendFrom, sendTo)
                               {
                                   Subject = "Test Email for compression",
                                   Body = "Test Email for compression"
                               };

              var ct = new ContentType() {MediaType = MediaTypeNames.Application.Zip, Name = "Sample.zip"};

              var attachfile = new Attachment(new MemoryStream(message), ct);
              myMessage.Attachments.Add(attachfile);

              emailClient.Send(myMessage);
           }
           catch (Exception ex)
           {
               ex.ToString();
               throw;
           }
       }

Here we have a simple SMTP client that takes in the byte array we get from the compression method we developed earlier.  Notice in the attachment we use a MemoryStream to add the compressed data into the email.

While this is a small alteration to most solutions out there, returning the compressed data this way offers the benefit of eliminating overhead associated with writing the data to a folder first, then moving it to its destination by keeping the compression completely in memory.

One of the annoying things about using the “Package Manager Console” in NuGet is that you’re constantly scrolling up and down the list of results.  If you’re like me, and you keep your console in the lower panel in VS2010, it’s not exactly easy to see a whole lot at once.

You can, however, output the results from your NuGet commands into a popup window by piping it out to “Out-GridView”.

Example

Execute the following command in the Package Manager Console:

List-Package –online | Out-GridView

This time, you’ll get your results in a nice pop-up window:

Multiple Commands?

Another weird thing I didn’t know, the following command is the equivalent to the one above in NuGet.

Get-Package –remote | Out-Gridview

I’m writing a series of blog posts to get a bit more in-depth on the new features of MVC 3.  I’m going to divide this topic into a number of posts to allow you to pick and choose what to learn about, and to attempt to keep your attention.  All of this in one blog post would be very lengthy and could get boring rather quickly.

In this post, I’ll keep it to a quick summary of the new features and a quick description of each.  We’ll get into more depth in future posts.

Overview of MVC 3

ASP.NET MVC is a wildly popular framework for web application development on the .NET platform, and MVC 3 is the latest iteration (currently in Release Candidate status as of the publication of this article.)

For those of you unfamiliar with the framework, I encourage you to visit the Official Microsoft ASP.NET MVC site and take a look.  Anyone who’s been frustrated with web development on the .NET platform up until now will likely find MVC to be a refreshing and exciting change to web development.  ASP.NET MVC truly feels like how web development should have been all along.  (For those new to MVC or interested in learning MVC in depth, watch this blog for a 10-part screencast series on ASP.NET MVC development, to be completed no later than 12/31/2010).

Some notes on MVC3:

• MVC 3 can be installed via the Web Platform Installer or via the Following Link: http://go.microsoft.com/fwlink/?LinkID=191797
• MVC3 is compatible with MVC2
  • There should be little to no upgrade path for MVC2 apps to work on the framework
  • Any MVC2 skills and knowledge can be applied to MVC3 development
• MVC3 can be installed side-by-side with MVC2
• Important Note: Unlike previous version the framework, MVC3 requires Visual Studio 2010 and .NET 4.0

What’s New: Feature List

Below is a categorized list of new features in the MVC3 Framework.  Stay tuned to the Tallan Enterprise Blog for a 4-part screencast series covering all of the enhancements listed here.

Framework and Tools

• Multiple View Engine Support
• “Razor” View Engine
  • New Default View Engine
  • Cleaner/More Concise than Web Forms
  • Less “ASP” Feel
• NuGet Package Management
  • Unix-Like package and dependency management
• Common Service Locator library
  • Simplifies Dependency Injection
  • Adds flexibility to DI and Dependency Resolution

View Enhancements

• New Web Helpers
  • Chart Helper
  • WebGrid Helper
• Unobtrusive Javascript and HTML 5
  • jQuery based client-side validation
  • jQuery based AJAX form and input

Controller Enhancements

• Global Action Filters
• Dynamic ViewModel object
• New Action Results
  • HttpNotFoundResult
  • HttpStatusCodeResult
• New Permanent Redirects (HTTP Status Code 301)
  • RedirectPermanent
  • RedirectToRoutePermanent
  • RedirectToActionPermanent
• Built in JSON Binding Support
  • Action methods support full model-binding from JSON based AJAX requests.

Model Validation Enhancements

• New .NET 4 Data Annotations
• Improvements to validation attributes
  • Allows for validation based on dependent properties
• IValidatableObject interface
  • Model-Level validation
  • Error-messages related to overall Model State

As each screencast is completed, I will update this post with links to each section.

Stay Tuned!

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.

S#arp Architecture is a project template for Visual Studio that will set you up with a ASP.NET MVC application that is already wired up for Dependency Injection and using nHibernate for data access.  more information can be found on the S#arp Architecture website and wiki.

My findings so far have been very positive.  Within about 45 minutes I had a web application with some basic CRUD functionality.  This functionality included unit testing at every layer.  It seems like a great way to start a project and easily promote best practices like dependency injection and test driven development.