My favorite ASP.NET MVC hooks #2: Action filter attributes

2009-06-22 by mookid8000 Leave a comment

Another simple place to hook your stuff in to the framework is action filters. An action filter is an attribute that derives from ActionFilterAttribute which is a convenience class containing the following methods for you to override:

void OnActionExecuting(ActionExecutingContext context);
void OnActionExecuted(ActionExecutedContext context);
void OnResultExecuting(ResultExecutingContext context);
void OnResultExecuted(ResultExecutedContext context);

void OnActionExecuting(ActionExecutingContext context);

void OnActionExecuted(ActionExecutedContext context);

void OnResultExecuting(ResultExecutingContext context);

void OnResultExecuted(ResultExecutedContext context);

A lot of the examples around the internet show how to use action filters to restrict access to controller actions or how to apply caching. I won’t do that here, because those concerns are boring. No, we care about how to make life easy for ourselves and how to write testable, non-breakable, maintenance-and-wrist-friendly code. That is, we reserve the right to be lazy.

A fine example on how to be lazy is by letting action filters fetch data for you to avoid repetitive repository gymnastics in every controller action – and I am actually going to be very lazy right now, because I wrote two posts on this topic earlier:

My favorite ASP.NET MVC hooks #1: Controller factory

2009-06-16 by mookid8000 Leave a comment

My favorite hook in the ASP.NET MVC framework is the controller factory. I like it so much because it serves as a very simple entry point to the application, thus providing the perfect place to insert an IoC container. My container of choice is Castle Windsor – not because I have tried any other container – I really can’t say that I have – but because I just happened to be introduced by a colleague to Windsor, and I have yet to experience anything it can’t do for me!

An ASP.NET MVC controller factory is an implementation of the IControllerFactory interface – a simple interface with two methods: one that provides an IController given a string and some more stuff, and one that allows the controller to clean up any resources it might have allocated. The interface looks like this:

public interface IControllerFactory
{
    IController CreateController(RequestContext requestContext, string controllerName);
    void ReleaseController(IController controller);
}

public interface IControllerFactory

{

IController CreateController(RequestContext requestContext, string controllerName);

void ReleaseController(IController controller);

}

As you can see, it provides a means to return a controller, given all sorts of information about the current request and what could be resolved as the controllerName from the request URL.

ASP.NET MVC accesses the controller factory via the ControllerBuilder class – so if we want to provide our own controller factory, we must install the factory before any requests get served. An obvious place to do this, is the Application_Start method inside the global.asax.cs file. This way our controller factory will be installed every time the web application starts up.

The controller factory can be set in two ways: 1) By providing the type of the factory, and 2) By providing an instance of the factory. Then it’s up to you if you want to let ASP. NET MVC instantiate the factory. I usually do it like this:

public void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    ControllerBuilder.SetControllerFactory(typeof(MyControllerFactory));
}

public void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

ControllerBuilder.SetControllerFactory(typeof(MyControllerFactory));

}

– and let ASP.NET MVC instantiate and store a singleton instance of my factory.

My controller factory implementation looks like this:

public class MyControllerFactory : IControllerFactory
{
    IWindsorContainer container = CreateWindsorContainer();

    public IController CreateController(RequestContext requestContext, string controllerName)
    {
        return container.Resolve<IController>(controllerName.ToLowerInvariant());
    }

    public void ReleaseController(IController controller)
    {
        container.Release(controller);
    }

    static IWindsorContainer CreateWindsorContainer()
    {
        return new WindsorContainer("windsor.config");
    }
}

public class MyControllerFactory : IControllerFactory

{

IWindsorContainer container = CreateWindsorContainer();

public IController CreateController(RequestContext requestContext, string controllerName)

{

return container.Resolve<IController>(controllerName.ToLowerInvariant());

}

public void ReleaseController(IController controller)

{

container.Release(controller);

}

static IWindsorContainer CreateWindsorContainer()

{

return new WindsorContainer("windsor.config");

}

Very simple. It takes the string, that was resolved as the controller name – e.g. “home”, “hOme”, “HOME” or whatever – and converts it to lower case, and then it uses that to look up a controller in my container. This means that all my controllers are registered in the container, and they will have all their dependencies automatically resolved when the container creates each instance.

A controller registration might look like this:

<castle>
    <components>
        <component id="home" type="WebSite.Controllers.HomeController, WebSite" />

        <!-- more registrations here... -->

    </components>
</castle>

</components>

</castle>

Simple – yet incredibly effective!

Creating a Windows service with Topshelf

2009-06-03 by mookid8000 Leave a comment

~~Update: This post still gets a fair amount of traffic, so I’d like to direct your attention towards my newer post on TopShelf 2.0: On The Bus With MassTransit #1~~
Update: Please go to the updated guide to Topshelf, which covers how to get started with Topshelf 3

Just wanted to share my experiences regard ing the super cool mini framework, Topshelf – a bi-product from the development of MassTransit. When Dru and the other guys were working on MassTransit, they needed to create Windows services a lot, which led to the separation of the Windows service stuff from the other stuff – and now they call it Topshelf.

You use Topshelf by creating a console application. In the Main method, you create a configuration, which you hand over to Topshelf. Then, everything just works as expected.

Topshelf requires that you to use an IoC container hidden behind the common service locator interface, which is neat because then it’s up to you to decide which container to use. In this example, I am using Windsor.

Creating a service is as simple as this:

namespace SomeService
{
  public class Program
  {
    [STAThread]
    public static void Main(string[] args)
    {
      const string serviceName = "some_service";

      var cfg = RunnerConfigurator.New(
        x =>
        {
          x.BeforeStart(
            s =>
              {
                Console.WriteLine("Starting {0}...", serviceName);
                ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(CreateWindsorContainer()));
              });

          x.AfterStop(
            s =>
              {
                Console.WriteLine("Stopping {0}...", serviceName);
                ((WindsorServiceLocator) ServiceLocator.Current).Dispose();
              });

          x.ConfigureService<SomeService>(
            c =>
            {
              c.WithName(serviceName);

              c.WhenStarted(s => s.Start());
              c.WhenStopped(s => s.Stop());
              c.WhenPaused(s => { });
              c.WhenContinued(s => { });
            });

          x.SetDisplayName("My funky service");
          x.SetDescription("This is a funky service that depends on MSMQ");
          x.SetServiceName(serviceName);

          x.DependencyOnMsmq();
        });

      Runner.Host(cfg, args);
    }
}

namespace SomeService

{

public class Program

{

[STAThread]

public static void Main(string[] args)

{

const string serviceName = "some_service";

var cfg = RunnerConfigurator.New(

x =>

{

x.BeforeStart(

s =>

{

Console.WriteLine("Starting {0}...", serviceName);

ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(CreateWindsorContainer()));

});

x.AfterStop(

s =>

{

Console.WriteLine("Stopping {0}...", serviceName);

((WindsorServiceLocator) ServiceLocator.Current).Dispose();

});

x.ConfigureService<SomeService>(

c =>

{

c.WithName(serviceName);

c.WhenStarted(s => s.Start());

c.WhenStopped(s => s.Stop());

c.WhenPaused(s => { });

c.WhenContinued(s => { });

});

x.SetDisplayName("My funky service");

x.SetDescription("This is a funky service that depends on MSMQ");

x.SetServiceName(serviceName);

x.DependencyOnMsmq();

});

Runner.Host(cfg, args);

}

Everything in the snippet above works as expected. Note how I create my Windsor container and store it behind WindsorServiceLocator, which is my trivial implementation of the IServiceLocator interface. This way, Topshelf will pull the specified service type(s) ( SomeService in the sample) from the container, and call the specified methods to start/stop (and possibly pause/resume) the service.

Note also how I specify that my service has a dependency on message queueing – neat!

Running and debugging the service is as easy as executing the .exe.

Installing/uninstalling can be done with

SomeService.exe /install
SomeService.exe /uninstall

1 2	SomeService.exe /install SomeService.exe /uninstall

Nifty!

Respect your test code #3: Make your tests orthogonal

2009-06-02 by mookid8000 1 Comment

When two things are orthogonal, it means that the angle between them is 90 degrees – at least in spaces with 3 dimensions or less. So when two vectors are orthogonal, they satisfy the property that there is no way to use the first one to express even the tiniest bit of what the other one expresses.

That is also how we should write our application code: methods and classes should be orthogonal to one another – i.e. no class should try to express what another class already expresses either in part or whole – therefore each class and each method should have only one responsibility, and thus one reason to change.

And test code is real code.

The corollary is that our tests should have only one single reponsibility as well.

That is why I hate tests that look like this:

public void CanRecordPayment()
{
    CreateMortgageDeed(1, new DateTime(2003, 3, 11));
    CreateMortgageDeed(2, new DateTime(2003, 6, 11));
    CreateMortgageDeed(3, new DateTime(2003, 3, 11));
    CreateMortgageDeed(4, new DateTime(2003, 3, 11));
    CreateMortgageDeed(5, new DateTime(2003, 9, 11));

    var mortgageDeeds = new DueTermsFinder(new MortgageDeedRepository())
        .FindDueTermsBefore(new DateTime(2003, 4, 1));
    
    Assert.AreEqual(3, mortgageDeeds.Count);

    mortgageDeeds = mortgageDeeds.OrderBy(m => m.CaseNo);

    Assert.AreEqual(1, mortgageDeeds[0].CaseNo);
    Assert.AreEqual(3, mortgageDeeds[1].CaseNo);
    Assert.AreEqual(4, mortgageDeeds[2].CaseNo);

    var result = new TermDebitRecorder()
        .CreateAndRecordTermDebits(mortgageDeeds);

    Assert.AreEqual(3, result.RecordedTermDebits.Count);

    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[0].TermDate);
    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[1].TermDate);
    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[2].TermDate);
    // .... etc!
}

public void CanRecordPayment()

{

CreateMortgageDeed(1, new DateTime(2003, 3, 11));

CreateMortgageDeed(2, new DateTime(2003, 6, 11));

CreateMortgageDeed(3, new DateTime(2003, 3, 11));

CreateMortgageDeed(4, new DateTime(2003, 3, 11));

CreateMortgageDeed(5, new DateTime(2003, 9, 11));

var mortgageDeeds = new DueTermsFinder(new MortgageDeedRepository())

.FindDueTermsBefore(new DateTime(2003, 4, 1));

Assert.AreEqual(3, mortgageDeeds.Count);

mortgageDeeds = mortgageDeeds.OrderBy(m => m.CaseNo);

Assert.AreEqual(1, mortgageDeeds[0].CaseNo);

Assert.AreEqual(3, mortgageDeeds[1].CaseNo);

Assert.AreEqual(4, mortgageDeeds[2].CaseNo);

var result = new TermDebitRecorder()

.CreateAndRecordTermDebits(mortgageDeeds);

Assert.AreEqual(3, result.RecordedTermDebits.Count);

Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[0].TermDate);

Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[1].TermDate);

Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[2].TermDate);

// .... etc!

}

Notice how this test is actually fairly decently structured – at least that’s what it initiallt looks like… but it actually tests a lot of things: it checks that the output of the DueTermsFinder is what it expects, testing the MortgageDeedRepository indirectly as well – and then it goes on to test the TermDebitRecorder … sigh!

If (when!) one of these classes changes at some point, because the requirements have changed or whatever, the test will break for no good reason. The test should break because you have introduced a bug, not because you made a change in some related functionality.

That is why I usually follow the pattern of AAA: Arrange, Act, Assert. Each test should be divided into discrete steps corresponding to 1) Arranging some data, 2) Triggering a computation or some state change, 3) Asserting that the outcome was what we expected. And if I am feeling idealistic that day, I also follow the principle of putting only one assertion at the end of each test.

I try to never do AAAAA (Arrance, Act, Assert, Act Assert) or AAAAAA, or AAAAAAA which is even worse.

Every test should have only one reason to break.