I must say though, I was inspired. Yes, I realise I had previously posted about one particular useful action filter, but I really haven’t done too much with them until now. Dino put forth some uses for them, which I believe are discussed in more detail in his MVC book:

• Using an action filter to figure out which button was pressed (on a multi-button form) and compartmentalise the resulting code path
• An action filter which automatically populates generic data on a view model (imagine a list of countries or some other static data required by your view)

We’ve all had some grief with the first scenario at some stage or another. It’s just not quite as easy to do as one would expect. The second allows you to abstract away some data population code and generally keep things a bit tidier than they otherwise would.

Today I created another action filter which takes a CSV list of data, parses it, and gives you a strongly-typed list of values. It looks like this:

[SplitString(Parameter="contentItemKeys", Delimiter=",")]
public virtual ActionResult GetItemInfo(IEnumerable<Guid> contentItemKeys)
{
}

So imagine that I have POSTed a comma-delimited list of GUIDs to this action. Normally, if there is one GUID then Asp.Net MVC should be able to resolve that properly and give you a list with one thing in it. However, if you have more than one GUID in that comma-delimited list, then you will have an empty list given to you. Why? Because the framework doesn’t know how to parse that list properly.

You could use a custom model binder to achieve the desired effect, but creating an action filter to do the same thing is much neater and much more flexible.

I’ve created an action filter called ‘SplitString’ and it works like this:

• The filter accepts a couple of arguments: the parameter you want to act on, and the delimiter to use.
• It overrides the OnActionExecuting method and looks for the specified parameter, first in the routing data, then in request data.
• It then finds the type that each item should be, using a little reflection.
• It then parses the list, converts each item in the parsed string to the desired type, and spits out the full list.

First, the class definition:

[AttributeUsage(AttributeTargets.Method)]
public class SplitStringAttribute : ActionFilterAttribute
{
    public string Parameter { get; set; }
    public string Delimiter { get; set; }

    public SplitStringAttribute()
    {
        Delimiter = ",";
    }

Inside OnActionExecuting, lets find the value we need to work with:

string value = null;
HttpRequestBase request = filterContext.RequestContext.HttpContext.Request;

if (filterContext.RouteData.Values.ContainsKey(this.Parameter)
	&& filterContext.RouteData.Values[this.Parameter] is string)
{
	value = (string)filterContext.RouteData.Values[this.Parameter];
}
else if (request[this.Parameter] is string)
{
	value = request[this.Parameter] as string;
}

Next we need to find the type to convert to. Specifically, we need to find the type of the generic argument which forms the type of the parameter we’re interested in. So if our parameter is IEnumerable<T>, I want to know what type T is. I’ve wrapped this up in a method:

Type listArgType = GetParameterEnumerableType(filterContext);

private Type GetParameterEnumerableType(ActionExecutingContext filterContext)
{
	var param = filterContext.ActionParameters[this.Parameter];
	Type paramType = param.GetType();
	Type interfaceType = paramType.GetInterface(typeof(IEnumerable<>).FullName);
	Type listArgType = null;

	if (interfaceType != null)
	{
		var genericParams = interfaceType.GetGenericArguments();
		if (genericParams.Length == 1)
		{
			listArgType = genericParams[0];
		}
	}

	return listArgType;
}

Here we simply:

• Find the type of the parameter using the filterContext
• Check to see if the type is IEnumerable<>. We do this simply by getting the interface and checking if it is not null
• Finally we get any generic arguments, check that there is exactly one, and then return that type. This is the type that we will convert each item in our CSV list to.

Next, we process our CSV string and create our container list:

string[] values = value.Split(Delimiter.ToCharArray(), StringSplitOptions.RemoveEmptyEntries);

Type listType = typeof(List<>).MakeGenericType(listArgType);
dynamic list = Activator.CreateInstance(listType);

We just split the string according to the delimiter that we need to use, then create a new generic list with the type we procured earlier. I’ve used a dynamic type here to make it much easier and more efficient to work with.

Next, we run through each value in our CSV list and add it to this new generic list:

foreach (var item in values)
{
	try
	{
		dynamic convertedValue = TypeDescriptor.GetConverter(listArgType).ConvertFromInvariantString(item);
		list.Add(convertedValue);
	}
	catch (Exception ex)
	{
		throw new ApplicationException(string.Format("Could not convert split string value to '{0}'", listArgType.FullName), ex);
	}
}

The real magic here is the type converter. We can simply pass it a type and an item to convert and it will just do it for you, in a nice generic way. This means you don’t have to manually support a known list of types – let the framework handle that for you!

Finally, and the real cherry on top, is that to make all this work, we simply substitute the original action parameter value with this new list that we’ve just created:

filterContext.ActionParameters[this.Parameter] = list;

The result is, your action parameter will now be populated correct with the parsed list of values, in a strongly typed fashion.

Download the full code file if you wish to inspect it further, or to use as you like.

Today me and @evadi discovered another little sparkle to this already very useful feature. I’ll highlight this specially to try and get across its importance:

The bundling framework (by default) will automatically favour JS files which end in .min.js.

This means that, when you enable default bundling in global.asax:

BundleTable.Bundles.EnableDefaultBundles();

Then you put some scripts in a folder:

And then you reference the bundle (as-per the new syntax) from your page:

<script src="@System.Web.Optimization.
BundleTable.Bundles.ResolveBundleUrl("~/MyScripts/js")"></script>

Only script.min.js is actually returned in the request; script.js is completely ignored. I tried changing the filename of the former to script-min.js and I found that both scripts were being included in the returned script, so there is definitely some logic going on to try to make use of existing minified scripts if they are available, provided they follow this convention.

Not only that, but files with a debug.js extension are completely ignored.

Controlling this behaviour

To begin with, you can turn this behaviour off by setting the EnableFileExtensionReplacements property on Bundle to false:

Bundle bundle = new Bundle("~/myscripts/js", new JsMinify());
bundle.EnableFileExtensionReplacements = false;

After doing this, all the scripts in the specified folder which match the file mask will be loaded. This flag does not seem to affect files with a debug.js extension, they are still ignored.

You can also have influence over which extensions get treated as “special”. For example’s sake, say your convention is to have all minified Javascript files have the extension of .minified.js, then you can register this extension by adding it to the FileExtensionReplacementList collection on the Bundle table:

BundleTable.Bundles.FileExtensionReplacementList.Add("minified");

It gets a bit sticky now because this opens up the possibility of including multiple minified files, especially if you have a mix of conventions in one directory. So what else can you do?

Build a custom bundle type

You can also create a new Bundle type which inherits from System.Web.Optimization.Bundle and alter the behaviour there. Luckily, a method named EnumerateFiles can be overridden, and a new implementation supplied. As another example, imagine that I wanted to filter out anything that contained the word ‘min’ in order to make sure that my Javascript files were processed by a funky custom minifier that I had just written, and I didn’t want to use files that had already been minified by some other process:

// CustomBundle.cs
public class CustomBundle : Bundle
{
  public CustomBundle(string vpath, IBundleTransform transform)
    : base(vpath, transform)
  {
  }

  public override IEnumerable<System.IO.FileInfo> EnumerateFiles(BundleContext context)
  {
    var files = base.EnumerateFiles(context);

    // select only non-minified files (according to naming convention)
    files = files.Where(c => c.Name.Contains("min") == false).ToList();

    return files;
  }
}

// global.asax.cs
Bundle bundle = new CustomBundle("~/myscripts/js", new JsMinify());
bundle.AddDirectory("~/myscripts", "*.js");
BundleTable.Bundles.Add(bundle);

Unfortunately even at this stage any files which end with debug.js are filtered out for us – so far I haven’t found a way to extend the framework to prevent this behaviour. I’m keeping in mind that this isn’t a final release, and that some work may be done in this area before the final version appears.

In conclusion, this certainly eases my mind when throwing the default bundler at a folder which contains a mix of minified and unminified libraries, knowing that – provided the filenames follow convention – it will pick out the correct one and minify it if necessary. Also, if needed I can provide implementations which can select the files I want to bundle up without having to manually add each individual file manually; for a large project, this can easily become unwieldy.

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.

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!

“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

• Part 1
• Part 2

I received some emails and comments asking a couple of different questions. How can this concept be applied to Sql Server without using EF? How can we create a dependency between Sql Server and our framework? This article is an attempt at answering these two questions, and as it turns out is also a great showcase for just how extensible our little framework is.. because I’m just about to hack it to bits. This article starts from where part 2 left off, so I strongly recommend you download the code from part 2 if you haven’t coded it to that point yourself.

Download source code from part 2

How can this concept be applied to Sql Server without using the Entity Framework?

In case you haven’t guessed by now, the answer to this is fairly simple – essentially we just create a new implementation of IVehicleRepository and utilise the normal Ado.Net objects to interact with our database. My solution in this article deals with the following:

• Refactoring VehicleRepository and moving some common code and methods into an abstract base class so that we can utilise some common bits and pieces in our new repository class
• Creating a new repository class SqlVehicleRepository, which uses Ado.Net to retrieve data from the database
• A crude Unit of Work implementation with transaction support

So, to being with lets set about refactoring our current repository class into a common base class. The main reason for doing this is because the code surrounding the cache and opting to do a database read is fairly common to any repository. Since we’ve already abstracted away the actual implementation of our cache, this refactoring is a fairly simple affair.

Our base class looks like this:

public abstract class VehicleRepositoryBase : IVehicleRepository
{
  public VehicleRepositoryBase()
    : this(new DefaultCacheProvider())
  {
  }

  public VehicleRepositoryBase(ICacheProvider cacheProvider)
  {
    this.Cache = cacheProvider;
  }

  /// <summary>
  /// Gets the key used to store vehicle data in the cache
  /// </summary>
  protected virtual string CacheKey
  {
    get { return "vehicles"; }
  }

  /// <summary>
  /// Gets the cache provider instance
  /// </summary>
  public ICacheProvider Cache { get; protected set; }

  /// <summary>
  /// Gets the vehicle data.
  /// </summary>
  public virtual IEnumerable<Vehicle> GetVehicles()
  {
    // First, check the cache
    var vehicleData = GetCachedData();

    // If it's not in the cache, we need to read it from the repository
    if (vehicleData == null)
    {
      // Get the data
      vehicleData = LoadData().ToDictionary(v => v.Id);

      if (vehicleData.Any())
      {
        // Put this data into the cache for 30 minutes
        Cache.Set(CacheKey, vehicleData, 30);
      }
    }

    return vehicleData.Values;
  }

  /// <summary>
  /// Loads the data from the data store
  /// </summary>
  protected abstract IEnumerable<Vehicle> LoadData();

  /// <summary>
  /// Inserts a new vehicle
  /// </summary>
  public abstract void Insert(Vehicle vehicle);

  /// <summary>
  /// Updates a vehicle
  /// </summary>
  public abstract void Update(Vehicle vehicle);

  /// <summary>
  /// Saves the data changes.
  /// </summary>
  public abstract void SaveChanges();

  /// <summary>
  /// Clears the data from the cache.
  /// </summary>
  public void ClearCache()
  {
    Cache.Invalidate(this.CacheKey);
  }

  protected Dictionary<Guid, Vehicle> GetCachedData()
  {
    var cacheData = Cache.Get(CacheKey) as Dictionary<Guid, Vehicle>;
    return cacheData;
  }
}

Note that it still implements IVehicleRepository for us, and simply marks most of the available methods as asbtract so that we can implement later. The key thing though is the concept surrounding GetVehicles() and LoadData(). The former is the consumer’s entry point to getting some data, where the latter is only concerned with actually reading the data from the data source.  This means that our base class can be concerned with all the caching stuff that we don’t want to have to worry about every time we create a new repository, and all we have to do with our specific repository implementations is actually load the data.

This leaves our VehicleRepository implementation without a GetVehicles() implementation, but instead has a LoadData() implementation:

public class VehicleRepository : VehicleRepositoryBase
{
  protected CachingDemoEntities DataContext { get; private set; }

  public VehicleRepository()
    : this(new DefaultCacheProvider())
  {
  }

  public VehicleRepository(ICacheProvider cacheProvider)
    : base(cacheProvider)
  {
    this.DataContext = new CachingDemoEntities();
  }

  /// <summary>
  /// Load the data from the data source
  /// </summary>
  protected override IEnumerable<Vehicle> LoadData()
  {
    return DataContext.Vehicles.OrderBy(v => v.Name).ToList();
  }

  /// <summary>
  /// Updates a vehicle
  /// </summary>
  public override void Update(Vehicle vehicle)
  {
    if (vehicle.EntityState == EntityState.Detached)
    {
      DataContext.AttachTo("Vehicles", vehicle);
    }
    DataContext.ObjectStateManager.ChangeObjectState(vehicle, EntityState.Modified);
  }

  /// <summary>
  /// Inserts a vehicle
  /// </summary>
  public override void Insert(Vehicle vehicle)
  {
    DataContext.AddToVehicles(vehicle);
  }

  /// <summary>
  /// Saves data changes to the data store
  /// </summary>
  public override void SaveChanges()
  {
    // Update or add new/existing entities from the changeset
    var changeset = DataContext.ObjectStateManager.GetObjectStateEntries(EntityState.Added | EntityState.Modified);

    DataContext.SaveChanges();

    var cacheData = GetCachedData();

    if (cacheData != null)
    {
      foreach (var item in changeset)
      {
        var vehicle = item.Entity as Vehicle;
        cacheData[vehicle.Id] = vehicle;
      }
    }
  }
}

In addition to removing GetVehicles() and adding LoadData(), I’ve just provided some constructor overloads so that we can still pass through implementations of ICacheProvider to our base class, since that is handling the caching mechanisms now. The rest of the class remains basically the same; remember to mark each method with the override keyword also.

Implementing SqlVehicleRepository

This is where things get more interesting. Now that we have a solid base class which abstracts away the management of the cache, we can go ahead and implement our Ado.Net version of our repository. Note that since I have an Entity Framework model set up with my Vehicle class and I’m just about to demonstrate a new implementation using the same database table, I’m just going to use that same generated class here also, even though it has some extra EF junk on it that we don’t really need for this implementation. If you want to separate the two out and create a completely separate plain entity for this step, feel free as long as you feel able to follow along with the following.

The main bulk of the work here is to implement LoadData(). We’re simply going to use all the old Ado.Net objects here, so if you’ve used them before there should be no surprises here. Lets load the data:

protected override IEnumerable<Vehicle> LoadData()
{
  var connection = CreateConnection();
  var command = new SqlCommand()
  {
    Connection = connection,
    CommandType = System.Data.CommandType.Text,
    CommandText = VEHICLE_SELECT
  };

  List<Vehicle> vehicles = new List<Vehicle>();

  using (connection)
  {
    connection.Open();

    var reader = command.ExecuteReader();

    if (reader.HasRows)
    {
      while (reader.Read())
      {
        var vehicle = new Vehicle()
        {
          Id = (Guid)reader["Id"],
          Name = (string)reader["Name"],
          Price = (decimal)reader["Price"]
        };

        vehicles.Add(vehicle);
      }
    }
  }

  return vehicles;
}

As you can see, we’re simply reading the data in using normal Ado.Net objects and spitting out a list of Vehicle. The only thing I haven’t shown you is the VEHICLE_SELECT constant, which I have defined at the top of my class. I’ve also defined constants for inserting and updating (which I will use in a moment), where the actual values to be inserted/updated will go in the place of the parameter names defined in the constant:

#region Query Constants

private const string VEHICLE_SELECT = @"Select * From Vehicle";
private const string VEHICLE_INSERT = @"Insert Into Vehicle (Id, Name, Price) Values (@Id, @Name, @Price)";
private const string VEHICLE_UPDATE = @"Update Vehicle Set Name=@Name, Price=@Price Where Id=@Id";

#endregion

We also need an implementation of CreateConnection(), which is as simple as it sounds. It reads the connection string from the application configuration file, and returns us a new instance of SqlConnection:

/// <summary>
/// Creates the SqlConnection instance
/// </summary>
private SqlConnection CreateConnection()
{
  return new SqlConnection(ConfigurationManager.ConnectionStrings["DemoConnectionString"].ConnectionString);
}

DemoConnectionString is a connection string entry which I have defined in my web.config file. You will need to add this entry and configure it to point to your own data store appropriately:

Since we are inheriting this class from VehicleRepositoryBase, this data is now automatically cached for us in the same way as the Entity Framework version was, thanks to our smart little framework. We’re not quite done yet though, as we still need to implement our inserting and updating.

Inserts, updates and units of work

The main thing to notice about the Entity Framework version is, thanks to the EF object context all the items to be inserted, updated and deleted are recorded and actioned later in a batch, rather than at the time we actually make the call to insert, update or delete something. This is the Unit of Work pattern in action, and we will implement a basic version of it here. The basic idea is to keep a list of things we want to insert and update for later, and when SaveChanges() is invoked, run through these lists and perform the database actions.

To start, I’ve created two lists at the top of my class to hold these changes, and also gone ahead and implemented the methods for inserting and updating:

private HashSet<Vehicle> _inserts;
private HashSet<Vehicle> _updates;

public override void Insert(Vehicle vehicle)
{
  if (!_inserts.Contains(vehicle))
    _inserts.Add(vehicle);
}

public override void Update(Vehicle vehicle)
{
  if (!_updates.Contains(vehicle))
    _updates.Add(vehicle);
}

Note: I haven’t shown the code here, but I’ve just initialised these lists in my constructor – I recommend you do the same.

SaveChanges() is where the real action happens. We’re going to run through each list in turn, build up the correct SQL statements, and then execute them against the server. We’re also going to update our cached values, clear the Unit of Work lists, and wrap the whole thing inside a transaction to keep us from getting erroneous data if something goes wrong.

public override void SaveChanges()
{
  var cached = GetCachedData();
  List<Vehicle> itemsToRecache = new List<Vehicle>();

  using (var connection = CreateConnection())
  {
    connection.Open();

    using (TransactionScope scope = new TransactionScope())
    {
      // Process inserts
      foreach (var vehicle in _inserts)
      {
        var command = new SqlCommand() { Connection = connection, CommandType = System.Data.CommandType.Text };

        command.CommandText = VEHICLE_INSERT;
        command.Parameters.Add(CreateParameter("Id", SqlDbType.UniqueIdentifier, vehicle.Id));
        command.Parameters.Add(CreateParameter("Name", SqlDbType.VarChar, vehicle.Name));
        command.Parameters.Add(CreateParameter("Price", SqlDbType.Decimal, vehicle.Price));

        command.ExecuteNonQuery();

        // Insert this vehicle into our cache
        itemsToRecache.Add(vehicle);
      }

      // Process updates:
      foreach (var vehicle in _updates)
      {
        var command = new SqlCommand() { Connection = connection, CommandType = CommandType.Text };

        command.CommandText = VEHICLE_UPDATE;
        command.Parameters.Add(CreateParameter("Id", SqlDbType.UniqueIdentifier, vehicle.Id));
        command.Parameters.Add(CreateParameter("Name", SqlDbType.VarChar, vehicle.Name));
        command.Parameters.Add(CreateParameter("Price", SqlDbType.Decimal, vehicle.Price));

        command.ExecuteNonQuery();

        itemsToRecache.Add(vehicle);
      }

      scope.Complete();
    }
  }

  itemsToRecache.ForEach(item =>
  {
    cached[item.Id] = item;
  });

  _inserts.Clear();
  _updates.Clear();
}

private SqlParameter CreateParameter(string name, SqlDbType type, object value)
{
  var param = new SqlParameter(name, type);
  param.Value = value;
  return param;
}

I’ve added a method which is just a wrapper for creating a basic SqlParameter, as it can be a bit fiddly to do inline otherwise. A hidden mechanic at work here is the updating of the cache; we keep a list of items to be re-cached, instead of just updating the cache directly while iterating through the items of work, because we don’t want the cache to be updated if for some reason the transaction doesn’t complete while processing later items. If an error occurs, we just want the data to remain as it was, both in the cache and from the database.

Remember to clear the lists once the work has been completed, or else the same items will be processed again when you next call SaveChanges() using the same instance.

This wraps up the SqlVehicleRepository implementation. The final thing to do is change your controller to use this implementation of the repository instead of the EF version we created in previous articles, like so:

public HomeController()
  : this(new SqlVehicleRepository())
{
}

So now, without any further change to the presentation layer you should have your data coming through your SqlVehicleRepository code path instead of your EF implementation, and it should all be cached appropriately. What we’ve effectively done is abstracted our caching code to a level where we can easily add new cached data stores to our application without too much work, and proved the concept by creating such a data store. You should be able to see now how you could easily add an Xml-based store to the application, for example.

How can we create a dependency between Sql Server and our framework?

As I mentioned at the top of the article, there were two pertinent questions about this work, and this is the second. Unfortunately, the answer is not as straight-forward as the first. As I discovered during my research for this article and through my own development tests, it’s actually very difficult to implement an Sql cache dependency between the application and Sql Server using the new caching framework provided by the .Net Framework 4. I never actually got it working, and I had to jump through quite a few hoops just to reach dead-ends where nothing would be cached.

In my mind, this is no bad thing as really I would not want to implement such a dependency. Whenever a record in the database changes, the whole cache is dropped and recreated. This does not scale well and as your dataset (and your user count!) grows, you will find that the cache will be constantly dropped and re-created, making it completely inefficient and pointless. A far better solution is to implement a smart caching strategy which does not create a live dependency against the database, and just accept that if for any reason your data changes through actions which do not route through your application, you will encounter stale data.

However..

That said, I changed tact and got a working solution, and as it turns out is yet another example of how flexible our little framework can be – although you might not like it..

My solution for this problem is to fall back to the original System.Web.Caching framework to implement our in-memory cache. We already have an interface set up from previous articles which allow us to abstract away an implementation of the cache, and so here we can just implement another one which uses the old framework.

If you’ve looked into doing this yourself, you’ve probably seen many arguments which form for and against using System.Web.Caching, mainly because of the namespace name. The ‘Web’ part of the namespace has unruly connotations in the context of our quest for abstraction and a layered approach to developing applications. The truth is the namespace is the only part which should cause concern; the actual cache works fine outside of a web context and can be used as normal.

My implementation here is specifically geared towards using the cache in conjunction with our Sql data implementation, and uses SqlCacheDependency to create the dependency between our data code and the database itself.

The dbEntryName parameter you see in the constructor is actually the name of the cache dependency element in our web.config file (I cover this in a moment), rather than the name of the database. It just so happens I’ve named it the same as my database.

Here is the implementation:

public class SqlDependancyCacheProvider : ICacheProvider
{
  private Cache _cache;

  public string DbEntryName { get; set; }

  public string TableName { get; set; }

  public SqlDependancyCacheProvider(string dbEntryName, string tableName)
  {
    _cache = System.Web.HttpRuntime.Cache;
    DbEntryName = dbEntryName;
    TableName = tableName;
  }

  public object Get(string key)
  {
    return _cache[key];
  }

  public void Set(string key, object data, int cacheTime)
  {
    SqlCacheDependency dep = new SqlCacheDependency(DbEntryName, TableName);
    _cache.Add(key, data, dep, Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(cacheTime), System.Web.Caching.CacheItemPriority.Normal, null);
  }

  public bool IsSet(string key)
  {
    return (_cache[key] != null);
  }

  public void Invalidate(string key)
  {
    _cache.Remove(key);
  }
}

They key thing to note here is that it implements our ICacheProvider interface. Because of this, we can just plug it into our SqlVehicleRepository instance to start using it!

public SqlVehicleRepository()
  : this(new SqlDependancyCacheProvider("CachingDemo", "Vehicle"))
{
}

You can of course pass it through to the constructor from the controller. “CachingDemo” in this case is the name of the caching dependency entry from the web.config file (more on this in a minute), and “Vehicle” is the name of the table that I want to create a dependency on.

There are a couple of things we need to take care of in order for the caching to actually work.

1. Enabling cache notification on the database tables

To set up the tables so that they can notify the cache when the data has changed, you need to run a couple of commands on your database and the table. Open up your Visual Studio Command Prompt from your start menu to run these.

These commands are:

aspnet_regsql.exe -S <server> -U <user> -P <password -d <database> -ed
aspnet_regsql.exe -S <server> -U <user> -P <password> -E -d <database> -t <tablename> -et

The first command will install the necessary tables and stored procedures which are required in order the change notification to work. In the command above, you will need to replace server, user, password and database with your own settings. If you connect to your database using Windows Authentication you can leave out the -U and -P parameters altogether.

The second command installs the triggers which effectively cause the cache to invalidate when ever the data is altered. This command is run against a specific table, so you will need to run it against every table you wish to enable caching on. Again, configure the parameters according to your own connection to Sql Server.

Run these commands now.

2. Web configuration for caching

The second part to getting all of this working is to add an entry into the web.config which tells the caching framework how to connect to your database, and other parameters like poll time and so on. Place the following inside your web.config file somewhere inside the system.web element:

<caching>
  <sqlCacheDependency enabled="true" pollTime="1000" >
  <databases>
    <add name="CachingDemo" connectionStringName="DemoConnectionString" />
  </databases>
  </sqlCacheDependency>
</caching>

The important thing is to make sure that connectionStringName points to a valid connection string setting within your configuration file. The ‘name’ attribute is just an arbitrary symbol given to this cache dependency element, so that it can be reference by name when you create instances of SqlCacheDependency.

And that’s all there is to it. You should now be able to load up your page, verify that data is coming from our new cache provider (using the power of debugging and breakpoints) and also change the database data and have the application reload the data from the data store and rehydrate the in-memory cache.

Hopefully those who enquired about these issues have found this useful!

Download the source code for part 3

These days, I like to use the excellent Colorbox for this sort of thing. In case you haven’t heard of it or used it before, it’s simply a brilliant jack-of-all-trades Javascript pop-up library based on the even more awesome jQuery. It can display anything in a pop-up, from arbitrary Html content, flash video and an image gallery depending on how you set it up. In the past I’ve used Thickbox for this sort of thing, but as it’s not maintained any more (not to mention Colorbox looks a lot nicer) I prefer this.

For this tutorial, imagine the following scenario:

• You have some sort of form you use to add/edit some data
• This form has the usual ‘Save’, ‘Cancel’ and ‘Delete’ buttons hanging off the bottom of it
• When the user clicks ‘Delete’, you want to show them a dialog asking the user if the really want to delete

For the delete confirmation you could just redirect the user to another page and show the confirmation there, but this method is cooler, not to mention ludicrously easy. Best of all, it doesn’t interfere too much with the .Net code you would have had to write anyway. So let’s get going.

1. Creating the Visual Studio Project

For this tutorial I am using the Asp.net Website project template from Visual Studio 2010. If you’re using VS2008, the website project template in there will also do fine, but you won’t get all the jQuery files you need. You can download them separately using the links below.

Create a standard Web Site project, choose a location to save your files and hit ‘Ok’:

2. Grab Colorbox & jQuery

Grab the latest version of Colorbox from their site (1.3.9 at the time of writing). Extract the archive to somewhere temporary on your hard-drive – the file structure inside the .zip file isn’t quite suited to just being plonked into a website, so we’ll need to sort that out first.

Basically for the purposes of this demo you will want to create a simple file layout for this stuff. As I’m using Visual Studio 2010 and the ‘Website’ project template, I already have a ‘Scripts’ folder set up for me. I’m just going to shove my Colorbox files in there in a sub-folder named ‘Colorbox’. I’ll put all the images and css files in there also. So, just grab the relevant files and folders from the archive you just downloaded and copy them into your website project so that you end up with a structure that looks like this:

You will also need to download jQuery, although if you’re using Visual Studio 2010 you will already have the appropriate libraries there ready for you when you create a new website project. If you need to download it, just save in the ‘Scripts’ folder as in the image above.

3. Register jQuery and Colorbox on the page

Now to register jQuery and Colorbox on our page. For now, I’m going to work entirely within Default.aspx, so we will just register our scripts in there instead of the master page (which is where this might normally go). Include jQuery, Colorbox and the Colorbox css files at the top of Default.aspx. Again, because I’ve used the new VS2010 website templates, it has already created me a nice project with a master page and so on. On Default.aspx, it’s also created references to content placeholders, including a HeadContent which will end up in the <head> tag on the page when it is rendered. I’m going to include my JS references in there, but really at the end of the day they just need to go somewhere on your page:

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

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

<script src="/Scripts/Colorbox/jquery.colorbox-min.js" type="text/javascript"></script>

<link href="/Scripts/Colorbox/colorbox.css" rel="stylesheet" type="text/css" />

</asp:Content>

By the way, the paths here assume that you’re running the website outside of a virtual directory – Visual Studio has a habit of creating website projects in virtual directories and not at the root of the URL. If you fire up the article source code, load it into VS and find that none of the scripts can be found when you test it out, that’s probably why. Simply click on the website project node in Solution Explorer, hit the F4 key to bring up the properties window and set the VirtualPath setting to just ‘/’ (without the quotes).

4. Create the dummy form

Imagine here that we have a form which is set up to edit the details of a piece of fruit from market (for the sake of the demo). I’m going to have a field which allows the user to edit the name of the fruit, and two buttons which perform a Save and a Delete operation. The only thing which is of importance to this demo is the Delete button; the rest of it is just fluff that I’m adding to give more ambience to the demo.

The form which I have created looks like this (I just created this under all the stuff that VS2010 gives you by default on default.aspx when you create a new web site project):

<div>
  <asp:Label runat="server" AssociatedControlID="FruitNameTextbox">Fruit name:</asp:Label>
  <asp:TextBox runat="server" ID="FruitNameTextbox" />
</div>

<div>
  <asp:Button Text="Save" ID="SaveButton" runat="server" />
  <asp:Button Text="Delete" ID="DeleteButton" runat="server" ClientIDMode="Static" />
</div>

5. Create the Colorbox dialog

Now for the first meaty parts of the demo. To create the dialog which will be shown by Colorbox, we simply define an area of Html which is to be shown inside the dialog when it is opened, and wrap the whole thing inside a div tag with display: none defined as its style. This is so that the dialog will not be displayed when the page is being viewed under normal circumstances. Furthermore, we attribute this area of Html with an Id so that Colorbox can pick it out.

For our dialog demo, we’re just going to ask the user to make sure that they really want to delete this item of fruit:

<div style="display: none;">
  <div id="dialog">

    <h1>Are you sure?</h1>
    <p>Are you sure you want to delete this fruit?</p>
    <p><strong>Note:</strong> This cannot be undone!</p>

    <asp:Button Text="Delete" ID="ConfirmDeleteButton" runat="server" ClientIDMode="Static" />
    <asp:Button Text="Cancel" Id="CancelDeleteButton" runat="server" ClientIDMode="Static" />

  </div>
</div>

In here you’ll notice that we’ve put another two buttons – one for actually deleting something, and one for cancelling the dialog. We’ve also given the inner div tag an ID of ‘dialog’ so that we can reference it when setting up Colorbox.

6. Making the buttons work!

Now that (almost!) everything is in place, we can work on the client-side stuff which will actually show the dialog and enable us to cancel out of it. First of all, showing the dialog takes only a few lines. Underneath the above code, we’ll open a new script tag and handle the click event of the DeleteButton to show the dialog box:

<script type="text/javascript">
  $(function ()
  {
    // 1. Wire up the delete button to show Colorbox:
    $("#DeleteButton").colorbox({ inline: true, href: "#dialog" });

    // 2. Handle the 'actual' delete button:
    $("#ConfirmDeleteButton").click(function()
    {
      $.fn.colorbox.close();
    });

    // 3. Handle the dialog cancel button:
    $("#CancelDeleteButton").click(function()
    {
      $.fn.colorbox.close();
      return false;
    });
  });
</script>

Here I am using some jQuery to pick up the page’s ‘load’ event using the short-hand $(function() {} );. Next, I’m using the selector of #DeleteButton to assign Colorbox to, so when that button is clicked, it will activate the Colorbox dialog. You can see as one of the parameters I’m passing the ID of our dialog code and I’m also setting the inline property to ‘true’, meaning that we want Colorbox to display content which is inline with our page, and not a piece of content hosted elsewhere (another URL for example).

Next, in step 2 we’re wiring up the dialog’s Delete and Cancel buttons. The two handlers look very similar in that all they really do is close Colorbox. However, the fundamental difference is that the handler for the Cancel button returns ‘false’, preventing the default action from happening. The ConfirmDeleteButton however will continue on and the page will post back as normal and fire the click handler for that button (we will create this in a moment), whilst still closing the dialog.

A Quick Note

You’ll notice that the buttons are attributed with ClientIdMode=”Static”. In case you haven’t seen it before, this is a new feature in .Net 4 which allows us to ensure that the Html output for a .Net control will have the same ID value as the one we give it when writing the code. This means that .Net won’t ‘mangle’ the name when used inside naming containers any more, and we can safely use the control ID from client-side code. Scott Guthrie has a detailed account ClientIdMode on his tech blog.

If you are using .Net 3.5, change the jQuery selector to instead:

$("input[id$=_DeleteButton]")

.. which basically says “Select any input element whose ID attribute value ends with _DeleteButton”, and you will get the same reliable result. You will also need to follow this for the buttons in the next section, which deal with cancelling and closing the dialog. Rick Strahl writes more about this on his blog.

7. The ConfirmDeleteButton handler

The last thing we need to do is wire up a server-side event handler for the actual delete button. This is done as normal in your code-behind (or inline if you prefer) and is no different to how you would normally handle this elsewhere. For my demo, I don’t actually have anything to delete, but I will handle it just the same way.

If we step back to the ConfirmDeleteButton for a second, and modify the mark-up to add in the name of the click handler:

<asp:Button Text="Delete" ID="ConfirmDeleteButton" runat="server"
ClientIDMode="Static" OnClick="ConfirmDeleteButton_Click" />

Then include the appropriate server-side handler in the code-behind:

protected void ConfirmDeleteButton_Click(object sender, EventArgs e)
{
  Response.Write("Fruit deleted!");
}

In my case I’m not deleting anything, but in your case this would be the place to kick off any database deletes or file modifications/changes required, then redirect the user somewhere useful.

Now, if you run the application you should be able to click on the initial delete button, have the dialog appear to reveal another delete button and a cancel button. Clicking this delete button will close the dialog but also display a message at the top of the screen (thanks to the click handler being executed). Clicking the cancel button will also close the dialog but should not refresh the page or perform any server-side postback (thanks to the ‘return false;’ in the Javascript click handler.

Download article source code

What we needed was a per-machine configuration solution which could allow different settings for different developers, which should fall-back to reading the standard web.config if a setting wasn’t available in the custom file. This would effectively allow the developer to override settings as they see fit without affecting other developers. The following class to handle this is what we came up with. Most developers have the proverbial “toolbox” of code which they will utilise in most projects, and this is a good one for your collection.

The requirements that we would like to fulfil with our implementation are:

• Allows the developer to request an application setting or connection string by key
• Should try to read the setting from an XML file from the root of the website. The file name should include the local machine name.
• If the setting or connection string cannot be found, the class should attempt to read it from the web.config using the standard ConfigurationManager framework.
• Because the machine-specific settings and connection strings should override the common settings from the web.config, an exception should be thrown if a setting which is defined in the host settings file does not also exist in the common settings file.
• For performance reasons, the settings file should be cached in memory to keep from reading from disk every time a setting is read.

Download the source code to accompany this article

For starters then, I’ve called my implementation the ConfigSettingsProxy. Here’s the model we’ll end up with by the time we’ve finished this article:

Let’s just go through each of the objects and define their purpose.

ConfigSettingsProxy

This is the main public interface for our configuration framework. The two methods GetAppSetting and GetConnectionString simply allow us to retrieve application settings and connection strings respectively. It knows about two instances of ISettingsReader – a HostSettingsReader, which reads settings and connection strings specific to the host machine, and a CommonSettingsReader, which reads settings and connection strings which are common to all hosts (read: all developers). In actual fact, ConfigSettingsProxy only knows about the interface ISettingsReader, but it’s how it deals with the idea of host settings and common settings which is the real purpose, as we shall see in the next section.

ISettingsReader

This is the interface which defines what a settings reader can do. In this case, it can at least read settings and connection strings.

HostSettingsReader

This is the first implementation class which implements ISettingsReader, and this deals with the reading of host-specific settings and connection strings. It knows to look for a specific file name containing the host machine’s name and it knows about the format the file is in. It also performs caching and cache invalidation for us.

CommonSettingsReader

This is the second implementation of ISettingsReader, which knows how to read settings which are common to all machines. This simply reads from the appropriate sections from the web.config via the standard ConfigurationManager.

Lets dive into some code, starting with ConfigSettingsProxy:

public class ConfigSettingsProxy
  {
    ISettingsReader _commonSettingsReader = null;
    ISettingsReader _hostSettingsReader = null;

    public ConfigSettingsProxy()
      : this(new HostSettingsReader(), new CommonSettingsReader())
    {
    }

    public ConfigSettingsProxy(ISettingsReader hostSettingsReader, ISettingsReader commonSettingsReader)
    {
      if (commonSettingsReader == null)
        throw new ArgumentNullException("commonSettingsReader");

      if (hostSettingsReader == null)
        throw new ArgumentNullException("hostSettingsReader");

      _commonSettingsReader = commonSettingsReader;
      _hostSettingsReader = hostSettingsReader;
    }

    public string GetAppSetting(string key)
    {
      var hostValue = _hostSettingsReader.GetSetting(key);
      var commonValue = _commonSettingsReader.GetSetting(key);

      if (hostValue == null)
        return commonValue;
      else
      {
        if (commonValue == null)
          throw new InvalidOperationException("Settings key '" + key + "' does not override a common setting");

        return hostValue;
      }
    }

    public string GetConnectionString(string name)
    {
      var hostValue = _hostSettingsReader.GetConnectionString(name);
      var commonValue = _commonSettingsReader.GetConnectionString(name);

      if (hostValue == null)
      {
        return commonValue;
      }
      else
      {
        if(commonValue == null)
          throw new InvalidOperationException("Connection string name '" + name + "' does not override a common connection string");

        return hostValue;
      }
    }
  }

This class takes care of calling into the correct settings reader for us. For both GetAppSetting and GetConnectionString methods, it reads the value from both the host settings and the common settings readers. If the host setting has not been specified, it returns the common setting. Otherwise, it returns the host setting only if the common setting has also been specified. This check is in place to reinforce the mechanism of overriding common settings. Imagine what would happen if a developer was able to program against his own host settings without the same keys also being available to the other developers who didn’t know about these settings?

Just to finish this class off, the default constructor just initialises the class with the default implementations for host and common settings, but also allows you to specify new implementations if your solution requires it, or for unit testing. I haven’t covered it here but the sample project for this post contains unit tests which demonstrates this.

This class only knows about the ISettingsReader interface, so lets define exactly what that is:

public interface ISettingsReader
{
  string GetSetting(string key);
  string GetConnectionString(string connectionStringName);
}

Simple stuff; it merely defines a contract for a class to retrieve settings and connection strings. The real power is in the following two implementation classes; HostSettingsReader and CommonSettingsReader.

HostSettingsReader

public class HostSettingsReader : ISettingsReader
{
  public string SettingsFilePath { get; private set; }

  public HostSettingsReader()
  {
    string machineName = Environment.MachineName;
    string fileName = string.Format("~/Settings_{0}.xml", machineName);
    string path = HostingEnvironment.MapPath(fileName);

    this.SettingsFilePath = path;
  }

  public HostSettingsReader(string path)
  {
    if (string.IsNullOrEmpty(path))
      throw new ArgumentNullException("path");
    this.SettingsFilePath = path;
  }

  public string GetSetting(string key)
  {
    XDocument settingsDocument = GetDocument();

    var query = from n in settingsDocument.Descendants("appSettings")
          from k in n.Elements()
          where k.Attribute("key").Value == key
          select k.Attribute("value").Value;

    return query.FirstOrDefault();
  }

  public string GetConnectionString(string name)
  {
    XDocument settingsDocument = GetDocument();

    var query = from n in settingsDocument.Descendants("connectionStrings")
          from k in n.Elements()
          where k.Attribute("name").Value == name
          select k.Attribute("connectionString").Value;

    return query.FirstOrDefault();
  }

  private XDocument GetDocument()
  {
    XDocument doc = MemoryCache.Default["LocalSettingsDocument"] as XDocument;

    if (doc == null)
    {
      if (!File.Exists(this.SettingsFilePath))
      {
        XElement element = new XElement("settings",
                    new XElement("appSettings"),
                    new XElement("connectionStrings"));

        doc = new XDocument(element);
        doc.Save(SettingsFilePath);
      }
      else
      {
        doc = XDocument.Load(this.SettingsFilePath);
      }

      var policy = new CacheItemPolicy();
      policy.AbsoluteExpiration = DateTime.Now.AddYears(1);
      policy.ChangeMonitors.Add(new HostFileChangeMonitor(new string[] { this.SettingsFilePath }));

      MemoryCache.Default.Add("LocalSettingsDocument", doc, policy);
    }

    return doc;
  }
}

The main things to note about this implementation are:

• By default, it looks for an Xml file in the root of the site called “Settings_<machine name>.xml”
• It does assume you’re using a web site. For other project types where a web context is unavailable, a new implementation could be provided to get the file from elsewhere (or use the second constructor which takes a path name)
• Settings are retrieved by simply opening up the file and looking for specific Xml nodes with the specified keys as attributes. If you think about it, the settings and connection strings in this file are specified in exactly the same way as you would in the web.config normally, meaning that they can just be copied out and pasted without further change in order to override a setting or connection string.
• Caching is provided by the new caching objects in the .Net Framework since version 4.0. Here the Xml setting files are cached for a year, but also specify a HostFileChangeMonitor so that when the settings are changed, the cache is invalidated and the new settings read on the next request.

The other implementation we have is for common settings. These are simply read from the configuration file as normal, but wrapped up in an implementation of ISettingsReader:

public class CommonSettingsReader : ISettingsReader
{
  public string GetSetting(string key)
  {
    return ConfigurationManager.AppSettings[key];
  }

  public string GetConnectionString(string connectionString)
  {
    if (ConfigurationManager.ConnectionStrings[connectionString] != null)
      return ConfigurationManager.ConnectionStrings[connectionString].ConnectionString;
    else
      return null;
  }
}

As you can see, it’s nothing more complex than the standard code you would normally write in order to retrieve settings from the configuration file.

That then is the complete implementation. A sample host settings file would look like the following. As mentioned, the Xml has been formatted deliberately so that keys can be copied in and out of the web.config file without change.

<?xml version="1.0" encoding="utf-8"?>
<settings>
  <appSettings>
  <add key="TestSetting" value="This is a test setting from the local settings file!" />
  </appSettings>
  <connectionStrings>
  <add name="TestConnectionString" connectionString="This is a test connection string from the local settings file!"/>
  </connectionStrings>
</settings>

Included in the downloadable source code for this project is a test website which contains the previous Xml settings file, plus this web page which demonstrates it working:

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

  public void Page_Load(object sender, EventArgs e)
  {
    var proxy = new ConfigurationProxy.ConfigSettingsProxy();

    ConfigurationSettingLiteral.Text = proxy.GetAppSetting("TestSetting");
    ConnectionStringLiteral.Text = proxy.GetConnectionString("TestConnectionString");
  }

</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title></title>
</head>
<body>
  <form id="form1" runat="server">
  <div>

    <p>Config setting: <asp:Literal runat="server" ID="ConfigurationSettingLiteral" /></p>
    <p>Connection string: <asp:Literal runat="server" ID="ConnectionStringLiteral" /></p>

  </div>
  </form>
</body>
</html>

In our production environment, we would create a class with static properties to match the configuration keys we had in our web.config file, using ConfigSettingsProxy to actually read the settings. This gave us hard-typed access to configuration whilst making them effectively override-able to match our own individual environments.

Download the article source code

In this post I’m going to cover how we can invalidate our repository cache in a more fine-grained, efficient way; instead of simply dropping and re-creating the cache every time something is written to the database, we’re essentially going to replace updated items directly into the cache just after we write them to the database. This will involved hooking into Entity Framework’s change-set and picking out the entities we’re interested in. I’m not going to cover the use of SqlDependancy here and the new wrappers within .Net 4.0.

If you download the sample project now, you can follow along with the article. The sample project (and this article) continue on from where part 1 in this series left off.

Over the course of this article, we’re going to do the following:

• Retrieve the objects which are being inserted, modified or deleted whenever we save changes
• Use the changeset to identify entities which need to be added, updated or removed from the cache
• Create a form to add and edit entities from the UI

So this means we’re basically doing our own invalidation, and the only way the cache will be updated is to update entities through our UI. Any changes made to the data outside of the UI (for example, in Management Studio) will not be picked up unless the cache is explicitly invalidated.

Lets start by making the changes to our IVehicleRepository class.

Here we add support for updating an entity, adding a new entity and persisting the changes to the data store. The new interface looks like this:

public interface IVehicleRepository
{
	void ClearCache();
	IEnumerable GetVehicles();
	void Insert(Vehicle vehicle);
	void Update(Vehicle vehicle);
	void SaveChanges();
}

We then add the implementation methods. Inserts and updates are fairly standard implementations. For updates, we have to mark the entity as being changed and attach it to the context. For inserts, we simply insert the entity into the Vehicles entity set.

public void Update(Vehicle vehicle)
{
	if (vehicle.EntityState == EntityState.Detached)
	{
		DataContext.AttachTo("Vehicles", vehicle);
	}
	DataContext.ObjectStateManager.ChangeObjectState(vehicle, EntityState.Modified);
}

public void Insert(Vehicle vehicle)
{
	DataContext.AddToVehicles(vehicle);
}

For the implementation of SaveChanges() to work efficiently, we need to make a small change to GetVehicles(). The change is essentially to store a Dictionary of vehicles into the cache instead of a plain list. We can (and should) still return a flat list from the method however to satisfy the interface contract. Here’s the method containing this revision:

public IEnumerable<Vehicle> GetVehicles()
{
	// First, check the cache
	var vehicleData = Cache.Get("vehicles") as IDictionary<Guid, Vehicle>;

	// If it's not in the cache, we need to read it from the repository
	if (vehicleData == null)
	{
		// Get the repository data
		vehicleData = DataContext.Vehicles.ToDictionary(v => v.Id);

		if (vehicleData.Any())
		{
			// Put this data into the cache for 30 minutes
			Cache.Set("vehicles", vehicleData, 30);
		}
	}

	return vehicleData.Values;
}

Note also that the previous version placed the sorting code here, at the point when the data is read from the database. I’ve simply moved the sorting code outside to the controller, since any entities which are added to the cache could cause it to become unsorted again.

Next, SaveChanges(). Here we simply retrieve the list of changed entities (updated or added), then call SaveChanges() on the underlying data context. Then, we run through the list of changed entities and update the cache directly with the changes. Because the cache now stores a Dictionary, we can simply update or add entities by indexing the dictionary with the ID of the vehicle. The dictionary itself will work out whether or not the entity needs to be added or updated depending on whether it is already in the dictionary or not.

public void SaveChanges()
{
	// Update or add new/existing entities from the changeset
	var changeset = DataContext.ObjectStateManager
                .GetObjectStateEntries(EntityState.Added | EntityState.Modified);

	DataContext.SaveChanges();

	var cacheData = Cache.Get("vehicles") as Dictionary<Guid, Vehicle>

	if (cacheData != null)
	{
		foreach (var item in changeset)
		{
			var vehicle = item.Entity as Vehicle;
			cacheData[vehicle.Id] = vehicle;
		}
	}
}

There are a couple of important things to note here:

• By calling SaveChanges() on the data context, we basically wipe out the changed entities. Therefore we need to get the list of changes entities before we actually process them and commit them to the data store.
• We call SaveChanges() before updating the cache because, if the data commit was to fail for whatever reason (validation or some other connection problem) then the cache will still reflect our unchanged data. We didn’t update the cache whenever Update() or Insert() is called for this reason also. We only want the cache to update when the data is actually persisted.

Updating the user interface

All of our code changes regarding data access is now complete. Turning our attention to the UI, we need to create a way to allow the user to insert and update entities via the site. To this end, I am going to create a MVC partial view containing the form, and use it from both the Create and Edit action views.

Firstly, create actions within in the HomeController class called Create and Edit. Note here that we actually create two methods for each action – a GET and a POST action. The actions which have been attributed with [HttpPost] will be called when the form posts back after the submit button has been clicked.

public ActionResult Edit(Guid id)
{
	var vehicle = Repository.GetVehicles().Single(v => v.Id == id);

	return View(vehicle);
}

[HttpPost]
public ActionResult Edit(Vehicle vehicle)
{
	Repository.Update(vehicle);
	Repository.SaveChanges();

	return RedirectToAction("Index");
}

public ActionResult Create()
{
	var newVehicle = new Vehicle() { Id = Guid.NewGuid() };

	return View(newVehicle);
}

[HttpPost]
public ActionResult Create(Vehicle vehicle)
{
	Repository.Insert(vehicle);
	Repository.SaveChanges();

	return RedirectToAction("Index");
}

These actions do pretty much as you would expect – when creating, we simply create a new instance of Vehicle and pass it to the view. When editing, we ask the repository to retrieve an instance of Vehicle for us, which in turn uses the cache if available.

Next we need to create the two views; one for creating and one for editing. Create each view by right-clicking on the GET action (the action without the HttpPost attribute) and use the dialogs to create your views. Remember to make them strongly-typed and accept a type of CachingDemo.Web.Models.Vehicle, as we’d like to pass instances of Vehicle to the views and be able to use them in a strongly-typed way from inside the view.

Open the Create view and put in some code to call a partial view named VehicleForm (created next) and pass it the model. If you’ve left the site using the standard template with the master page, the following code should appear within the MainContent placeholder:

<h2>Create</h2>

<% Html.RenderPartial("VehicleForm", Model); %>

<p><%: Html.ActionLink("Back to list", "Index") %></p>

Open the Edit view next copy in exactly the same code as the Create view. The partial view we create next is going to do all the work for us.

Create a partial view inside the /Views/Home folder called “VehicleForm”:

<%@ Control Language="C#"
Inherits="System.Web.Mvc.ViewUserControl<CachingDemo.Web.Models.Data.Vehicle>" %>

<% using (Html.BeginForm()) {%>
    <%: Html.ValidationSummary(true) %>

	<%: Html.HiddenFor(m => m.Id) %>

    <div>
        <%: Html.LabelFor(model => model.Name) %>
    </div>
    <div>
        <%: Html.TextBoxFor(model => model.Name) %>
        <%: Html.ValidationMessageFor(model => model.Name) %>
    </div>

    <div>
        <%: Html.LabelFor(model => model.Price) %>
    </div>
    <div>
        <%: Html.TextBoxFor(model => model.Price, String.Format("{0:F}", Model.Price)) %>
        <%: Html.ValidationMessageFor(model => model.Price) %>
    </div>

    <p>
        <input type="submit" value="Save" />
    </p>

<% } %>

You can also achieve this of course by right-clicking the folder, selecting ‘View’ and then creating a partial view using the dialog. Just remember to make it strongly-typed as we’re going to be passing it an instance of Vehicle as its model from the parent view.

When you’re done, you should now be able to debug the application and watch as single items are retrieved from the cache and replaced in-situ when they are updated. This is more efficient than simply invalidating the whole cache and will scale better when dealing with more users and more data.

Download the sample project

Until next time..

First of all, an overview of the structure of the application and what we’re going to be doing. The example application and the code snippets below are written in C#.

• Creating a bog-standard MVC 2 application
• Use the Entity Framework to read our data from the database, and utilise a repository pattern to wrap up this database interaction
• Wrap up the new .Net 4.0 caching objects ObjectCache and MemoryCache to give ourselves another extensibility point, and aid unit testing
• Tie all this together using the MVC front-end

By the way – the tools I am using here are Visual Studio 2010 Professional (Express would work too, although I haven’t tested it), Asp.Net MVC 2, .Net Framework 4 and Sql Server 2008 Express Edition. Although I’ve mentioned it above, there isn’t any unit testing being done in the downloadable demo application (as it’s not the real focus of this article) but, as you will see, the techniques we will implement lend itself very well to being unit testable and you are free to carry out this testing if you wish.

First of all, let’s set up the database and our entities!

I’ve created a simple test database with one table to store some information about Vehicles, and it looks like this:

Create a new Asp.Net MVC2 project (not the ‘empty’ one) – I’ve called mine CachingDemo.Web. We’re going to use the Entity Framework to interact with this database, so go ahead and add a new Entity Data Model item to the project. I’ve chosen to create this data model in the Models folder, inside a new folder I’ve created called Data which, after we’re done, will give us this sort of structure:

Right-click on the Data folder and add a new ADO.NET Entity Data Model:

Create your connection to the database. Here I’ve used my own local instance of SqlExpress:

Keep all the default names and options for saving the connection and entity objects:

Choose the test database and again just select all the default options for now:

Just click ‘OK’ through the rest of the options until the wizard is complete and you’re faced with the entity model designer. It should only have the Vehicle entity on it, which exactly maps to our database schema.

That’s all for the Entity Framework stuff for now. Next we need to start creating some objects to help us retrieve this data and actually perform the caching. This next step is where the main focus of the article is, as it actually uses the caching objects and wraps it up into a neat repository class.

We’re also going to wrap up the Cache objects so that we can swap it out later, with either a Mock caching object for unit testing, or to implement a 3rd-party caching framework such as Memcached. Start by creating the interface for our cache provider:

public interface ICacheProvider
{
	object Get(string key);
	void Set(string key, object data, int cacheTime);
	bool IsSet(string key);
	void Invalidate(string key);
}

Next, we will provide a default implementation which uses the .Net 4 ObjectCache and MemoryCache objects to provide caching support. In order to do this, you will need to add a reference System.Runtime.Caching assembly:

This default implementation looks like the following:

public class DefaultCacheProvider : ICacheProvider
{
	private ObjectCache Cache { get { return MemoryCache.Default; } }

	public object Get(string key)
	{
		return Cache[key];
	}

	public void Set(string key, object data, int cacheTime)
	{
		CacheItemPolicy policy = new CacheItemPolicy();
		policy.AbsoluteExpiration = DateTime.Now + TimeSpan.FromMinutes(cacheTime);

		Cache.Add(new CacheItem(key, data), policy);
	}

	public bool IsSet(string key)
	{
		return (Cache[key] != null);
	}

	public void Invalidate(string key)
	{
		Cache.Remove(key);
	}
}

The main points to note here are:

• We’ve created a private property which allows us to retrieve the actual cache object. This just returns the static .Net4 MemoryCache object. Because it’s static, you will receive the same cache object back every time you call it, and other users using the cache will also be served the same cache object. This is key – once the data is in the cache, it is cached for all users.
• In our simple implementation of the Set method, we create a cache policy which caches the item for the following 30 minutes. Once the 30 minutes has passed, the item is dropped from the cache.
• We have another couple of utility methods which allow consumers to check that an item has been cached, and also one which allows us to force the removal of a cached object.

Now that we have an interface for our cache and that the .Net Caching objects are wrapped up, we can go ahead and create our data repository. For our simple demo application we’re just going to use this repository straight from the MVC Controller. For more advanced or complex applications you will probably want to create another business layer on top of this repository which contains more coarse-grained business methods.

Again, we will have an interface for our repository and then implement it, making use of our Entity Framework objects we created earlier. The interface looks like this:

public interface IVehicleRepository
{
	void ClearCache();
	IEnumerable GetVehicles();
}

Pretty simply, it defines contract which allows us to get vehicles. It also allows us to clear it’s data cache, which may not be needed in a real application but I’ve included it here for convenience. The implementation of this interface looks like the following:

public class VehicleRepository : IVehicleRepository
{
	protected CachingDemoEntities DataContext { get; private set; }

	public ICacheProvider Cache { get; set; }

	public VehicleRepository()
		: this(new DefaultCacheProvider())
	{
	}

	public VehicleRepository(ICacheProvider cacheProvider)
	{
		this.DataContext = new CachingDemoEntities();
		this.Cache = cacheProvider;
	}

	public IEnumerable GetVehicles()
	{
		// First, check the cache
		IEnumerable vehicleData = Cache.Get("vehicles") as IEnumerable;

		// If it's not in the cache, we need to read it from the repository
		if (vehicleData == null)
		{
			// Get the repository data
			vehicleData = DataContext.Vehicles.OrderBy(v => v.Name).ToList();

			if (vehicleData.Any())
			{
				// Put this data into the cache for 30 minutes
				Cache.Set("vehicles", vehicleData, 30);
			}
		}

		return vehicleData;
	}

	public void ClearCache()
	{
		Cache.Invalidate("vehicles");
	}
}

Note that we have a constructor which allows us to specify an implementation of ICacheProvider (our caching interface), but that also the default constructor just passes it an instance of our DefaultCacheProvider. Now we can easily create our repository with all the default dependencies but at the same time we have the flexibility to provide another implementation when we need one.

GetVehicles() is where the main bulk of the work is done. There is a specific pattern at work where which makes working with the cache easy and robust:

1. Try and retrieve the vehicle data from the cache using our ‘vehicles’ key.
2. If the data is not there, we re-create the data from the database (our entity data model). Note that we store the data into the same vehicleData variable from when we tried to read the cache.
3. If there is any data to store, we set it into the cache using the same ‘vehicles’ key, and set the timeout as 30 minutes.
4. Return the vehicle data

Our ClearCache() implementation is also there, which simply invalidates our ‘vehicles’ data.

Now we have all we need to go ahead and create the controller and the interface to display and invalidate this data. First we will set up the constructors on our controller – here I have just made use of the Home controller rather than creating a new one. The constructors follow a similar pattern which allow us to specify an implementation of IVehicleRepository, or provide another one for unit testing:

public class HomeController : Controller
{
	public IVehicleRepository Repository { get; set; }

	public HomeController()
		: this(new VehicleRepository())
	{
	}

	public HomeController(IVehicleRepository repository)
	{
		this.Repository = repository;
	}

Continue with the Index action, and retrieve the data from the repository. This is all the data access code we need to write as far as the controller is concerned – because we’ve abstracted all the actual caching code away, we no longer need to worry about whether the data is being cached or not; our controller code will work regardless:

public ActionResult Index()
{
	ViewData["Message"] = "Welcome to my caching demo!";
	return View(Repository.GetVehicles());
}

I’ve just left in the ViewData message which was there from the project creation, but changed it slightly. The main point about this code is the call to Repository.GetVehicles(), and the fact that we are passing it as the model to the Index view. I also have another Index action here which acts on form post – as you’ll see in a moment, I have a button on my form which allows us to invalidate the cache from the page for convenience, so we can test that the cache is being dumped and re-created properly. This action looks like the following:

[HttpPost]
public ActionResult Index(FormCollection form)
{
	Repository.ClearCache();
	return RedirectToAction("Index");
}

On to the view next. The resulting view I have simply writes out the data into a table, with a button underneath allowing us to invalidate the cache. I’ve already put some sample data into my database, which you might also want to do now:

The code for this view (which I have just put into the Index view) looks like this:

<h2>Car data:</h2>

<table cellpadding="0" cellspacing="0" border="0">
	<tr>
		<th>Id</th>
		<th>Name</th>
		<th>Price</th>
	</tr>

	<% foreach (var vehicle in Model) { %>

		<tr>
			<td><%: vehicle.Id.ToString() %></td>
			<td><%: vehicle.Name %></td>
			<td><%: string.Format("{0:c0}", vehicle.Price) %></td>
		</tr>

	<% } %>

</table>

<% using (Html.BeginForm()) {  %>
	<input type="submit" value="Invalidate Cache" id="InvalidateButton" name="InvalidateButton" />
<% } %>

Now we have completed the code for the application. Test the application by performing the following steps (make sure you have put in some test data):

1. Load the page. You should see your test data appear
2. Alter the data directly on the database using Sql Server Management Studio or some other means which allows you to directly alter the table
3. Refresh the page. Your changes should not appear, because on this page load the old data is coming from the cache, not the database.
4. Press the button to invalidate the cache. The page will reload and your database changes will now be shown.

To dive further into the mechanics, when debugging the application, you can place breakpoints around the caching code to see the data going into and being retrieved from the cache. After the first page load, you will notice that the data is coming straight from the cache and is not hitting the entity framework code at all. If you click the button to invalidate the cache, you will notice that the cache is now empty and that it has to go back to the database to update the cache.

Stale data is an issue when employing the use of any caching framework, and we will be dealing with this in two ways over the next two parts of this series: using the new SqlDependency wrapper, and also using a more code-centric technique in the third part. In the project source code I have included the full MVC project and the Sql file which allows you to install the demo database into your own Sql Server instance.

Download the project source code