Home > Programming > ASP.Net MVC Framework and Castle

ASP.Net MVC Framework and Castle

I’m currently trying to convert my personal football office pool software into a more generic package that other people could use and potentially buy for running their own pools in a much easier fashion than email and Excel spreadsheets. I’ve been looking for a reason to try out the ASP.Net MVC framework and this seemed like the perfect opportunity.

So far, I’ve been pretty pleased with the framework though the documentation is really quite sparse. Thank God for Google. Since I’ve started doing the Castle Windsor heroin at work, I definitely wanted to add that to this project. I couldn’t find any exact examples on the web to steal from so I’m writing up the very easy experience here, only partially stealing from Phil Haack’s example using StructureMap.

It’s a two step process. First, create a class that inherits from DefaultControllerFactory. I called mine CastleWindsorContollerFactory (hey I’m nothing if not boring) and stuck it in a Framework folder in my web project. It looks like this:

using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Web.Mvc;
using System.Web.Routing;
using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
using Castle.Core.Resource;

namespace FootballOfficePool.Framework
{
    public class CastleWindsorControllerFactory : DefaultControllerFactory
    {
        protected override IController CreateController
            (RequestContext requestContext, string controllerName)
        {
            try
            {
                IWindsorContainer container = 
                    new WindsorContainer
                        (new XmlInterpreter(new ConfigResource("castle")));
                return container[controllerName.ToLowerInvariant()] as IController;                
            }
            catch (Exception e)
            {
                return base.CreateController(requestContext, controllerName);
            }
        }
    }
}

The catch block is really more for debugging because if you’re doing Dependency Injection right, chances are you aren’t going to have a parameterless constructor which that line in the catch block requires. I’ll eventually change that to a log and throw probably. One thing to note, the way I’m doing it requires all my controllers to be outlined in the config file which will probably quickly become a pain in the ass. I can think of at least a couple of ways around it but until it is a PITA, I’m doing it the easy way. The ID in your config file for the controllers should be the name of your Controller class minus the “Controller” suffix. So for example, here’s my config file entry for my HomeController:

 

Once all that’s done, all you gotta do is update your Global.asax.cs file like so:

        protected void Application_Start()
        {
            ControllerBuilder.Current.SetControllerFactory(new CastleWindsorControllerFactory());
            RegisterRoutes(RouteTable.Routes);
        }

And you’re in business with Castle auto-wiring up all your dependencies assuming you have the required ones defined in the config file.

In other news I didn’t know, the Escape character in Microsoft SQL is the single quote. That’s 20 minutes of my life I’ll never get back.

The Daily Palliative: You Aren’t Doing It Right

Categories: Programming Tags:
  1. No comments yet.
  1. No trackbacks yet.