Making sure ‘this’ points to exactly what you think it does in Javascript is one of the challenges that a new programmer to the language has to overcome. Script# makes this somewhat easy for us because it tries to make sure it points to exactly what we’d expect it to if we were writing a normal C# app.

Take this snippet, for example:

jQueryObject buttons = jQuery.Select(".homepageCreateButton");

buttons.MouseOver(delegate(jQueryEvent e)
{
	jQueryObject button = jQuery.This;
});

Here I’m selecting some buttons and applying a click handler. The generated code here is as you would expect, where jQuery. This clearly translates to $(this):

var buttons = $('.homepageCreateButton');

buttons.mouseover(function(e) {
    var button = $(this);
});

What happens though when I start using the C# keyword ‘this’ in my delegate?

jQueryObject buttons = jQuery.Select(".homepageCreateButton");

buttons.MouseOver(delegate(jQueryEvent e)
{
	jQueryObject button = jQuery.This;

	object a = this;
});

This gets compiled to:

var buttons = $('.homepageCreateButton');
buttons.mouseover(ss.Delegate.create(this, function(e) {
    var button = $(this);
    var a = this;
}));

.. which is not quite the same thing. As soon as the Script# compiler has detected that I am making use of the ‘this’ pointer it wraps the delegate call in a method and changes the context of the code inside the delegate so that ‘this’ points to the current instance of the class. This is of course the exact behaviour we would expect and love in C#, and for the most part this is also a good thing in Javascript. By the way, this transformation also happens if you implicitly access a class-level member without using the ‘this’ keyword.

However, look at what it has done to our jQuery selector; we expected ‘this’ to be the current element that we are handling the ‘mouseover’ event for, but now that has changed and we are effectively selecting the current instance of the class through a jQuery selector, which of course is nonsense.

To get around this and make sure that you’re accessing the actual object that you want inside the delegate, you should make use of the CurrentTarget property on jQueryEvent:

jQueryObject button = jQuery.FromElement(e.CurrentTarget)

Just be careful when you intend to use ‘this’ and ‘jQuery.This’ together in a delegate, as they will not behave as you would expect in this case.

I’ve just put another release out for .Net Image Processor, my image processing and resizing code library for .Net and GDI, which includes a number of new filters, including:

• Greyscale
• Sepia
• Invert
• Image watermark
• Text watermark

The first three also introduce a small framework for applying any sort of single pixel-based filter (as opposed to kernal-based filters) where you can simply create an implementation of PixelFilter and supply your own algorithm for manipulating a single pixel (a blog post is forthcoming on this soon).

You can grab the latest version from the project homepage, or you can update the Nuget package from within Visual Studio. To see how to use all of the available filters, have a scan of the documentation.

So what’s coming next?

I’m looking into using a couple of third-party libraries for a couple of prominent issues:

• PNG lossy compression isn’t supported very well by GDI+, so I’m looking into using libpng to help with this
• An issue has come up with multi-page TIFF files, but I think I can solve this one with another library
• Batch processing

Both of these issues will be looked at for the 1.3 release.

This is a pet project which I’ve had around for a while now, which started off as a simple wrapper for GDI+ which allows you to create thumbnails from images. It’s turning into something a bit more than that, with an extensible filter framework where filters can be chained together. Also supports image conversion to/from Jpeg, PNG, TIFF, Bmp and GIF.

The idea is that over time I will be developing more and more filters which can be plugged in, with support coming for batch processing and asynchronous processing. Finally, the entire project is all open-source and free!

All the documentation for how to use it is all contained within the project homepage (there is more technical documentation to come), so without further ado here are all the links you need:

• Project home page
• Usage / documentation
• Source explorer

Nuget Support

What’s more, the project is also hosted on Nuget – so if you run Visual Studio 2010 with the excellent Nuget extension you can just install the project from there. The package name is Simplicode.ImageProcessor.

I would love to hear any feedback or issues you have if you use the library – you can get in touch with me directly or post a review on the project site!

I’ve been struggling with this for a couple of hours now and found a solution that I would like to share.

The problem is this: I added a resource file to my project as an Embedded Resource, configured the namespace as “Resources.Dialog” and set its Custom Tool property to “PublicResXFileCodeGenerator”. I then added some string resources to the file.

After inspection of the generated code file, everything looks normal. Next, I need to be able to access my resources dynamically, rather than simply using my Dialog resource class directly.

You would be tempted to do something like this:

ResourceManager dialogResources = new ResourceManager(typeof(Resources.Dialog));
string myString = dialogResources.GetString("MyString");

This would work in theory, but instead (for me at least) it throws this nasty exception on the call to GetString():

MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture

I might be expecting this exception if I hadn’t provided a neutral culture resource file (which are basically your ‘fallback’ resources if you’re not using a supported culture), or if I had defined the resource file in a different assembly, but I’m not. This is a simple neutral culture resource file, in the same assembly as where the resource is being used from.

I don’t know why its doing this, but I do know what I changed to finally fix it.

The class which is generated by the resource file exposes a static ResourceManager instance which is set up to manage itself – so the solution is to use this rather than create your own!

Therefore, the above code becomes:

ResourceManager dialogResources = Resources.Dialog.ResourceManager;
string myString = dialogResources.GetString("MyString");

.. and the exception goes away.

The default project template for Asp.Net is pretty functional out of the box, but an interesting feature is that new templates install jQuery and jQuery UI out of the box! In fact, jQuery UI now comes pre-installed as a Nuget package if you’ve got the latest MVC3 Tools Update (April 2011). If you’re following this while sitting at a MVC3 project already in development, you can simply install the latest jQuery UI repository release using Nuget from within Visual Studio, and you will get the same thing.

In case you did not know, you can start working with jQuery UI pretty quickly and easily by just including the style sheet and script in your layout page like so (your actual file names may vary slightly):

<link href="@Url.Content("~/Content/themes/base/jquery.ui.all.css")" type="text/css" rel="stylesheet" />
<script src="@Url.Content("~/Scripts/jquery-ui-1.8.11.min.js")" type="text/javascript"></script>

This will get you working with a basic jQuery UI theme for all the components and controls which come with the framework. However, if you want to update the project with another jQuery theme to better suit your requirements, then you can do it like this.

First of all, find a theme using the jQuery UI theme roller that takes your fancy. For this example, I’ve chosen “Redmond” as it fits in nicely with the default Asp.Net MVC 3 theme, but you can chose any theme or construct your own. When you click download, it will ask you which components you want to download themes for – just leave it at the default, which is all of them – and click ‘Download’. After .zip archive has been downloaded, extract it to somewhere temporary, and explore its contents.

You will get a file structure which looks like this:

Everything you need is inside the “css” folder – if you open that now you will see a single folder which is named after the theme you just picked from the jQuery UI site. If you’ve created a custom theme, then it will be named “custom-theme” or something to that effect. You can also give it your own folder name if you change the options under ‘advanced theme options’ when you download the theme.

Right-click and copy this folder. Now, browse to the /content/themes folder of your MVC 3 application and paste the folder there. Now you should have two folders in that location – one called “base” and your new theme folder (see right).

All we need to do now is include this folder in your Visual Studio project. The easiest way to do this is to turn on “Show All Files” by clicking the little button at the top of the Solution Explorer tool window, then right-click on the theme folder (which will appear with a white folder icon) and select “Include in Project”.

Now, all that’s left is to include the theme’s style sheet into your layout, and you are done:

<link href="@Url.Content("~/Content/themes/redmond/jquery-ui-1.8.13.custom.css")" type="text/css" rel="stylesheet" />

Now your new theme will be automatically applied to any jQuery UI components you are using in your application. Here’s a shot of it working with jQuery UI Buttons:

You can apply the same process to any additional themes you want to install, just line up all your themes in the same folder and include the relevant style sheet on your pages.

I was able to get along to the UK Techdays event this year in Fulham (it’s a free event – if you can make the time, it’s worth the trip) to hear about the latest developments in the Windows Azure platform and also Windows Phone 7.

The first day concerned Azure, and it was interesting to hear from the Microsoft techies and evangelists (David Gristwood, Eric Nelson, Steve Plank and Keith Burns amongst others) , giving us the low-down on features and also running through some brief tutorials which showed us how to accomplish specific tasks, like deploying new web roles and administering our platform instances via the control panel. Steve Plank took us through some more interesting aspects like connecting your local Active Directory to your virtual network in the Cloud, and also spoke a bit about AppFabric and the various components which it concerns.

It was also interesting to hear from external businesses which have based their products on Azure, or had at least implemented a solution based on the technology. The general theme is that, if you can move your infrastructure to the Cloud and get rid of your existing hardware, it really is a no-brainer. If anyone is thinking of implementing a high-volume scalable solution, then they can use this technology at a fraction of the price. One of the speakers mentioned that they were able to turn their six-figure annual costs into a three-figure monthly payment!

Keith Burns later gave a talk on the Sql Azure platform, and the differences between it and Sql Server. To be honest, the differences are fairly small (no full-text indexing or non-clustered indexes yet) but the sizes and costs seem a little prohibitive to me. There’s a maximum of 50Gb per database (which is a LOT of storage anyway, but you still have that limit whereas the Table Storage and Blob Storage technologies are vastly larger) and there’s a cost of £6.06 per Gb of data. There are of course data transfer costs, but these only apply when your data leaves the data centre – having an Sql Azure database which is used by a Web Role (for example) located within the same data centre will not occur any costs.

The second and third days were completed engulfed by Windows Phone 7 announcements, demos and more case studies from external developers (including Cocktail Flow and Very Software). They demonstrated how their applications were put together, design decisions they made and also presented demos of their applications running.

Brandon Watson was there as the keynote speaker and gave some insight to the progress of the phone at the application repository which seems to be growing at some rate (1000+ new apps every month?). He also outlined some of the changes coming with the new “Mango” phone update and the new developer tools (which were released a couple of days ago).

Oren Nachman gave some great talks and demos surrounding performance on the phone, and highlighted the quite obvious issues with the standard list box and how slow it was with any decent size list. He walked through a simple broken application and attempted to fix it by using the proper debugging tools and applying the appropriate fixes. He also (on the second day) gave an account of the differences between Silverlight 4 on the desktop, and the forthcoming Silverlight 4 for the phone.

Later, Andy Wigley (Appamundi) was on hand to give a complete demo of the new Sql CE for WP7, and set about converting an existing Xml-based phone app into one which makes use of Sql and Linq. By the looks of it, it’s almost exactly the same as the LinqToSql technology which is available on the desktop, except there is no designer. So all your entity classes and contexts must be created manually (including specifying all of the appropriate attributes and making sure you fire the usual PropertyChanging/PropertyChanged event pair for the change tracking to work. You could see during the demo that this is all very manual, and it will be a good day when some designer tools for this technology are released.

There was also a run-through of Expression Blend 4 by Brennon Williams, who showed us some design issues and how to create a functional prototype of an application using Sketchflow. No discredit to Brennon at all, because his talk and the presentation was excellent, but the topic missed the mark a little for me as a developer. I would have liked to have seen more about how to use Blend from the point of view of the developer – creating your application code in Visual Studio and then applying some gloss using Blend (which is what I understood the workflow to be). Nevertheless, I did enjoy it and hopefully such a topic will be part of next year’s event.

All in all, a good three days and would definitely attend next year. They do give out freebies and prizes and such, including geeky T-shirts, tokens for AppHub subscriptions (yours truly being the recipient of one such token!) and even phones!

Currently as part of my work I find myself doing a lot of client-side work (using the excellent ScriptSharp I might add) and this does involve a lot of calls to the server for bits and pieces via an AJAX call. I’ve decided to dedicate an entire controller to serve such requests.

However, I want to be able to prevent actions on this controller being run from normal requests through the browser. Normally I would just make sure that such requests done through AJAX are through a POST request, but there is a better way.

Inside an action, you can inspect the current HttpContext.Request object and use the handy IsAjaxRequest() extension method to test whether the current request is being executed from an AJAX request or not. You can then just throw an exception if the request isn’t AJAX based when you expect it to be. Performing this in every action would become tiresome though if you have a lot of them. So – you can wrap it up inside a handy Action Filter!

[AttributeUsage(AttributeTargets.Class|AttributeTargets.Method)]
public class AjaxOnlyAttribute : ActionFilterAttribute
{
  public override void OnActionExecuting(ActionExecutingContext filterContext)
  {
    if (filterContext.HttpContext.Request.IsAjaxRequest())
    {
      base.OnActionExecuting(filterContext);
    }
    else
    {
      throw new InvalidOperationException("This operation can only be accessed via Ajax requests");
    }
  }
}

The code is very simple and really just wraps up code we would otherwise write in each action. Except now you can do this:

public partial class HomeController : Controller
{
  [AjaxOnly]
  public ActionResult SomeAjaxAction()
  {
    return Content("Hello!");
  }
}

Now, if you were to try accessing this action via the browser through the url /Home/SomeAjaxAction, you will hit the exception that is thrown from inside the filter. However, Ajax requests made through jQuery or some other client-side method will pass as normal. Notice how that it doesn’t break the normal GET/POST semantics; we can make Ajax actions which just return some data true Ajax GET requests without worrying about someone inadvertently linking to the action.

You can also mark the controller itself with this attribute so that all the contained actions inherit this behaviour if that is what is required.

While I wait for my shiny new download of Visual Studio 2010 SP1 to install, I just thought I’d share a couple of awesome frameworks and plugins I’ve been working with over this past week or so. Some of them might not be news to the masses but I have recently found them to be extremely useful.

Plupload
Demo/Download

This one blew me away. From the makers of the excellent TinyMCE rich-text editor comes Plupload – a free web-based multiple file upload utility that you can use within your sites to upload multiple files in an asynchronous fashion. The genius about it is that it detects the current browser capabilities and automatically chooses the best option for the user (based on the developer’s initial configuration). For example, it can be configured to use a Flash interface to do the upload in the first instance, but if Flash is not available then it will automatically fall back to another technology, including an Html5 or Google Gears implementation. The developer just has to configure the plugin with what technologies should be included based on their various capabilities and the rest is done for you.

What’s more it supports chunked transfer, so uploading massive files should be no problem.

I’m starting to use this in my home-brew projects now with great success and I will heartily recommend it over any licensed/paid products you might use! I plan to write a tutorial article in the near future showing how you can integrate this product into your Asp.Net MVC applications.

jQuery Context Menu plugin
Demo/Download

This plugin is great for showing context menus within your interface. You basically set up an unordered Html list which describes your menu, and then bind it to those items via a jQuery selector which should activate the menu when right-clicked. You then get notification about which item was clicked, which menu entry was selected and even where the mouse cursor was when you clicked it.

I’m not writing just about this plugin though. This site has all sorts of little bits and pieces on it which come in extremely handy. Just looking through their blog posts (it’s a shame these individual plugins aren’t more visible from the home page) I found these cool little plugins which have made my life easier:

• Select-box
• Word Wrap

And links to other plugins and utilities which I haven’t tried yet, including this gem: jCrop (in-browser image cropping tool).

It’s a great resource and is now on my list of blogs to regularly check for cool stuff!

jQuery-UI Sortables
Demo/Download

jQuery-UI itself is not news (if you’re not using this yet, you should be), and to be honest, neither is the Sortable module within. But the discovery I made was that it’s not just for sorting ordered lists – it can be used to create interesting portlet-type interfaces where people can drag content around and lay out pages exactly how they want (think Pageflakes or iGoogle). This kind of power is extremely easy to achieve and works great!

It seems that within hours of posting my article on Dependency Injection: A Beginner’s Guide, some things had changed with the Ninject packages available on Nuget.

The article uses the package ‘Ninject.MVC3′ package, which also depends on Dave Ebbo’s WebActivator framework, allowing access to some really early initialisation for things such as dependency injection.

Today it seems as if the package includes Ninject 2.2 and has changed to ‘Ninject.Web.Mvc3′ (and I see they’ve also registered similar namespaces for MVC1 and MVC2), and this package no longer depends on WebActivator which means you don’t get the normal AppStart_NinjectMvc3.cs file in the root of your project. It also looks as though they’ve gotten rid of NinjectServiceLocator and now instead we have NinjectDependencyResolver.

However, WebActivator doesn’t seem strictly necessary. Taking these changes into account, I can just register all of my bindings in the Application_Start() method in global.asax.cs along with all my MVC routes and so on, and everything works as intended:

protected void Application_Start()
{
  IKernel kernel = new StandardKernel();
  kernel.Bind<ILogger>().To<Logger>();
  DependencyResolver.SetResolver(new Ninject.Web.Mvc.NinjectDependencyResolver(kernel));

  AreaRegistration.RegisterAllAreas();

  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);
}

Update

22nd Feb: And it looks as though everything is back to the way it was, with the Ninject.MCV3 package now available again. So pretty much everything in this post can be ignored but I’ll keep it up for historical archiving purposes!

This article intends to outline the concept of Dependency Injection and its uses within a software engineering project. From Wikipedia.org:

“it is a design pattern that separates behaviour from dependency resolution, thus decoupling highly dependent components”.

Later, I demonstrate the use of Dependency Injection within the context of an Asp.Net MVC 3 application.

Dependency Injection (or DI) allows us to provide implementations and services to other classes for consumption in a very loosely-coupled way. The key tenet is that such implementations can be swapped out for other implementations by changing a minimal amount of code, as the implementation and the consumer are linked by contract only.

In C#, this means that your service implementations should adhere to an interface, and when creating consumers for your services you should program against the interface and not the implementation, and require that the implementation is provided for you, or injected rather than having to create instances yourself. Doing this allows your classes to not worry about how dependencies are create nor where they come from; all that matters is the contract.

Dependency Injection by Example

Let’s go through a simple example where DI could be useful. First, let’s create an interface (the contract) which will allow us to perform some task, say logging a message:

public interface ILogger
{
  void LogMessage(string message);
}

Notice that nothing about this interface describes how the message is logged and where it is logged to; it simply has the intention of recording a string to some repository. Next, lets create something which uses this interface. Say we create a class which watches a particular directory on disk, and logs a message whenever the directory is changed:

public class DirectoryWatcher
{
  private ILogger _logger;
  private FileSystemWatcher _watcher;

  public DirectoryWatcher(ILogger logger)
  {
    _logger = logger;
    _watcher = new FileSystemWatcher(@"C:\Temp");
    _watcher.Changed += new FileSystemEventHandler(Directory_Changed);
  }

  void  Directory_Changed(object sender, FileSystemEventArgs e)
  {
    _logger.LogMessage(e.FullPath + " was changed");
  }
}

The key thing to notice is that the constructor, we require that something which implements ILogger is given to us, but again notice that we don’t care about where the log goes or how it is created. We can just program against the interface and not worry about it.

This means that in order to create an instance of our DirectoryWatcher we must also have an implementation of ILogger ready. Let’s go ahead and create one which logs messages to a text file:

public class TextFileLogger : ILogger
{
  public void LogMessage(string message)
  {
    using (FileStream stream = new FileStream("log.txt", FileMode.Append))
    {
      StreamWriter writer = new StreamWriter(stream);
      writer.WriteLine(message);
      writer.Flush();
    }
  }
}

Let’s create another which logs messages to the Windows Event Log:

public class EventFileLogger : ILogger
{
  private string _sourceName;

  public EventFileLogger(string sourceName)
  {
    _sourceName = sourceName;
  }

  public void LogMessage(string message)
  {
    if (!EventLog.SourceExists(_sourceName))
    {
      EventLog.CreateEventSource(_sourceName, "Application");
    }
    EventLog.WriteEntry(_sourceName, message);
  }
}

Now we have two separate implementations which log messages in very different ways, but both implement ILogger, which means that either one can be used where an instance of ILogger is required. Now we can create an instance of DirectoryWatcher and have it use one of our loggers:

ILogger logger = new TextFileLogger();
DirectoryWatcher watcher = new DirectoryWatcher(logger);

Or, by just changing the right-hand side of the first line we can use our other implementation:

ILogger logger = new EventFileLogger();
DirectoryWatcher watcher = new DirectoryWatcher(logger);

This happens without any changes to the implementation of DirectoryWatcher, and this is the key concept. We are injecting our logger implementation into the consumer, so that the consumer doesn’t have to create this instance on its own. The example shown is trivial, but imagine using this in a large-scale project where you have several dependencies which need to be used by many times more consumers, and then suddenly a requirement comes along which means that the method of logging a message must change (say  the messages are required to be logged into Sql Server for auditing purposes). Without some form of dependency injection, you will have to carefully examine the code and change anything which actually creates an instance of a logger and then uses it. In a large project this can be painful and error prone. With DI, you would just have to change the dependency in one place, and the rest of your application will effectively absorb the change and immediately start using the new logging method.

Essentially, it solves the classic software problem of high-dependency and allows you to create a loosely-couple system which is extremely agile and easy to change.

Dependency Injection Containers

Many DI frameworks which you can download and use go a step further and employ the use of a Dependency Injection Container. This is essentially a class which stores a mapping of types and returns the registered implementation for that type. In our simple example we would be able to query the container for an instance of ILogger and it would return an instance of TextFileLogger, or whichever instance we had initialised the container with.

This has the advantage that we can register all of our type mappings in one place, usually in an “Application Start” event, and that gives us quick and clear visibility as to what dependencies we have in the system. Also, many professional frameworks allow us to configure the lifetime of such objects, either creating fresh instances every time we ask for one, or re-using instances across calls.

The container is usually created in such a way that we can get access to the ‘Resolver’ (the thing which allows us to query for instances) from anywhere in the project.

Finally, professional frameworks usually support the concept of “sub-dependencies”, where a dependency has itself one or more dependencies to other types also known to the container. In this case, the resolver can fulfil these dependencies too, giving you back a full chain of correctly created dependencies according to your type mappings.

Let’s create ourselves a very simple DI container to see how the concept works. This implementation doesn’t support nested dependencies, but does allow you to map an interface to an implementation and then query for that implementation later:

public class SimpleDIContainer
{
  Dictionary<Type, object> _map;

  public SimpleDIContainer()
  {
    _map = new Dictionary<Type, object>();
  }

  /// <summary>
  /// Maps an interface type to an implementation of that interface, with optional arguments.
  /// </summary>
  /// <typeparam name="TIn">The interface type</typeparam>
  /// <typeparam name="TOut">The implementation type</typeparam>
  /// <param name="args">Optional arguments for the creation of the implementation type.</param>
  public void Map<TIn, TOut>(params object [] args)
  {
    if (!_map.ContainsKey(typeof(TIn)))
    {
      object instance = Activator.CreateInstance(typeof(TOut), args);
      _map[typeof(TIn)] = instance;
    }
  }

  /// <summary>
  /// Gets a service which implements T
  /// </summary>
  /// <typeparam name="T">The interface type</typeparam>
  public T GetService<T>() where T : class
  {
    if (_map.ContainsKey(typeof(T)))
      return _map[typeof(T)] as T;
    else
      throw new ApplicationException("The type " + typeof(T).FullName + " is not registered in the container");
  }
}

Then, we can construct a small program which creates a container, maps the types, and then queries for a service. Again a simple compact example but imagine what this would look like in a much larger application:

class Program
{
  static SimpleDIContainer Container = new SimpleDIContainer();

  static void Main(string[] args)
  {
    // Map ILogger to TextFileLogger
    Container.Map<ILogger, TextFileLogger>();

    // Create a DirectoryWatcher using whatever implementation for ILogger contained in the DI container
    DirectoryWatcher watcher = new DirectoryWatcher(Container.GetService<ILogger>());
  }
}

Dependency Injection with Asp.Net MVC 3 and Ninject

Asp.Net MVC 3 is very well suited to dependency injection as it provides hooks and the framework for any DI vendor to create a suitable container. Whenever any controllers or views are created, they pass through the DI container for dependency resolution. It also provides a global way to retrieve dependencies from anywhere within the project.

Ninject (http://ninject.org/) is a DI container especially written for .Net and now has code to specifically make use of the new DI features in MVC 3. Coupled with the latest versions of MVC 3, VS2010 and the popular Nuget Package Manager, it is extremely easy to get up and running with DI using Ninject within an Asp.Net MVC 3 project.

Let’s run through an example of using Ninject with MVC 3 to implement our small logging framework. This tutorial requires a few bits and pieces which you should install if you haven’t done so already:

• VS2010 (Professional or Express editions)
• Asp.Net MVC 3 (http://www.asp.net/mvc/mvc3)
• Nuget Package Manager for VS2010 (http://nuget.codeplex.com/)

If you wish, you can download the complete project source to follow along with.

Once the above has been installed, let’s begin:

1) Open up VS2010 and create a new MVC 3 Web Application (I’ve called mine MvcNinjectExample):

After this screen you will get a dialog asking you to choose an Empty application or an Internet Application – just choose “Empty”.

2) Once the project has loaded, right-click ‘References’ in solution explorer and choose “Add library package reference..” (this is Nuget in action):

3) On the left, choose “Online” then search for Ninject. In the search results, you should be able to see “Ninject.Mvc3”. Select this and click the ‘Install’ button:

This will download Ninject and all the other things it needs in order to work, including the WebActivator library, which gives us a place to create our dependencies.

4) Once everything has installed, look for the ‘AppStart_NinjectMVC3.cs’ file which has now appeared in your solution and open it:

namespace MvcNinjectExample {
  public static class AppStart_NinjectMVC3 {

    public static void RegisterServices(IKernel kernel)
    {
      //kernel.Bind<IThingRepository>().To<SqlThingRepository>();
    }

    public static void Start() {
      // Create Ninject DI Kernel
      IKernel kernel = new StandardKernel();

      // Register services with our Ninject DI Container
      RegisterServices(kernel);

      // Tell ASP.NET MVC 3 to use our Ninject DI Container
      DependencyResolver.SetResolver(new NinjectServiceLocator(kernel));
    }
  }
}

You can see here how the Ninject Kernel is created, which is responsible for resolving our types. In RegisterServices() is where we would bind our contracts to our implementations. The DependencyResolver is used to register Ninject for type injection, which means that Ninject is used to resolve dependencies whenever they are needed by MVC.

Let’s have a quick look at how we can apply our logger to this and get our controllers using our logging framework.

5) Add a new folder called ‘Logging’ to the solution and create a new class called ILogger, and copy this code into it (overwrite the class which has been generated for you):

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

namespace MvcNinjectExample.Logging
{
  public interface ILogger
  {
    void LogMessage(string message);
  }
}

Create another class called TextFileLogger and copy this code into it, again overwriting the class which was generated for you:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.IO;
using System.Web.Hosting;

namespace MvcNinjectExample.Logging
{
  public class TextFileLogger : ILogger
  {
    public void LogMessage(string message)
    {
      string path = Path.Combine(HostingEnvironment.MapPath("~/app_data"), "log.txt");
      using (FileStream stream = new FileStream(path, FileMode.Append))
      {
        StreamWriter writer = new StreamWriter(stream);
        writer.WriteLine(message);
        writer.Flush();
      }
    }
  }
}

You will need to include a using statement for System.IO at the top of the file to get access to the FileStream class. Once all done, you should end up with your code and solution looking like this:

Note that I have also created the App_Data directory (which is needed by the TextFileLogger) so that the log file has somewhere to go.

6) Now, head back to your “AppStart_NinjectMVC3.cs” file and set up the binding for this class:

public static void RegisterServices(IKernel kernel)
{
  kernel.Bind<ILogger>().To<TextFileLogger>();
}

7) Finally, lets create a controller which uses it. Right-click on the ‘Controllers’ folder in Solution Explorer, select ‘Add >’ and choose the ‘Controller…’ option at the very top. Give it a name of “HomeController” and press enter.

Inside this controller, we create a constructor which takes a parameter of MvcNinjectExample.Logging.ILogger, and we’ll save that into a class-level private variable for later. Ninject is going to give us the actual implementation of that in accordance with the bindings we set up in the last step. I’ve also modified the index view so that is just returns a piece of content rather than looking for a view; this is just to prevent exceptions from being thrown as I’m not creating a view for this example. Finally, I’ve also called into the logger from the index view to log a message for us. After we run the page, we should get a log.txt file in the App_Data directory containing our message.

After my modifications, the controller now looks like this:

public class HomeController : Controller
{
  MvcNinjectExample.Logging.ILogger _logger;

  public HomeController(MvcNinjectExample.Logging.ILogger logger)
  {
    _logger = logger;
  }

  public ActionResult Index()
  {
    _logger.LogMessage("Running index page!");

    return Content("Message logged");
  }
}

This is the general pattern you will use with Dependency Injection in MVC; including your dependency contracts in your controller’s constructor, having Ninject fulfil the dependencies for you then consuming them from within the controller actions.

Let’s put a breakpoint in the constructor and see what we get when we run the project:

As we intended, without doing any additional code than what I’ve presented here, we now have an instance of ILogger passed to us when the controller was created. This has happened because MVC has effectively asked Ninject to create this controller for us. During creation, Ninject has noticed that it requires an implementation of ILogger in order to create this controller. Since we registered a binding to ILogger in AppStart_NinjectMVC3, it knows how to create one of these and so it can go ahead and completely fulfil the dependency on this controller. Hence we have Dependency Injection.

If I let the solution run again, we should hit the Index action and the text file will be created with the log message inside it:

If you were to change this to use our EventFileLogger implementation as in one of the earlier examples, you will see that all you would have to do is create the implementation, make it implement ILogger and then register it in your kernel bindings. No changes to any controllers which use it are necessary.

You should now follow this pattern when adding more dependencies to your project, and as your project scales in size you will see how easy it is to manage components in a loosely-coupled fashion even within a web project such as this. It gives you lots of flexibility and ultimately makes your projects a lot more maintainable and easy to change and adapt.

Download project source code