Archive for the 'ASP.NET MVC' Category

Creating a Simple IoC Container

Inversion of Control (IoC) is a software design principle that describes inverting the flow of control in a system, so execution flow is not controlled by a central piece of code. This means that components should only depend on abstractions of other components and are not be responsible for handling the creation of dependent objects. Instead, object instances are supplied at runtime by an IoC container through Dependency Injection (DI).

IoC enables better software design that facilitates reuse, loose coupling, and easy testing of software components.

At first IoC might seem complicated, but it’s actually a very simple concept. An IoC container is essentially a registry of abstract types and their concrete implementations. You request an abstract type from the container and it gives you back an instance of the concrete type. It’s a bit like an object factory, but the real benefits come when you use an IoC container in conjunction with dependency injection.

An IoC container is useful on all types of projects, both large and small. It’s true that large, complex applications benefit most from reduced coupling, but I think it’s still a good practice to adopt, even on a small project. Most small applications don’t stay small for long. As Jimmy Bogard recently stated on Twitter: “the threshold to where an IoC tool starts to show its value is usually around the 2nd hour in the life of a project”.

There are many existing containers to choose from. These have subtle differences, but all aim to achieve the same goal, so it’s really a matter of personal taste which one you choose. Some common containers in .NET are:

While I recommended using one of the containers already available, I am going to demonstrate how easy it is to implement your own basic container. This is primarily to show how simple the IoC container concept is. However, there might be times when you can’t use one of the existing containers, or don’t want all the features of a fully-fledged container. You can then create your own fit-for-purpose container.

Using Dependency Injection with IoC

Dependency Injection is a technique for passing dependencies into an object’s constructor. If the object has been loaded from the container, then its dependencies will be automatically supplied by the container. This allows you to consume a dependency without having to manually create an instance. This reduces coupling and gives you greater control over the lifetime of object instances.

Dependency injection makes it easy to test your objects by allowing you to pass in mocked instances of dependencies. This allows you to focus on testing the behaviour of the object itself, without depending on the implementation of external components or services.

It is good practice to reduce the number of direct calls to the container by only resolving top-level objects. The rest of object-graph will be resolved through dependency injection. This also prevents IoC-specific code from becoming scattered throughout the code base, making it easy switch to a different container if required.

Implementing a Simple IoC Container

To demonstrate the basic concepts behind IoC containers, I have created a simple implementation of an IoC container.

Download the source and sample code here

This implementation is loosely based on RapidIoc, created by Sean McAlindin. It does not have all the features of a full IoC container, however, it should be enough to demonstrate the main benefits of using a container.

public class SimpleIocContainer : IContainer
{
    private readonly IList registeredObjects = new List();

    public void Register<TTypeToResolve, TConcrete>()
    {
        Register<TTypeToResolve, TConcrete>(LifeCycle.Singleton);
    }

    public void Register<TTypeToResolve, TConcrete>(LifeCycle lifeCycle)
    {
        registeredObjects.Add(new RegisteredObject(typeof (TTypeToResolve), typeof (TConcrete), lifeCycle));
    }

    public TTypeToResolve Resolve()
    {
        return (TTypeToResolve) ResolveObject(typeof (TTypeToResolve));
    }

    public object Resolve(Type typeToResolve)
    {
        return ResolveObject(typeToResolve);
    }

    private object ResolveObject(Type typeToResolve)
    {
        var registeredObject = registeredObjects.FirstOrDefault(o => o.TypeToResolve == typeToResolve);
        if (registeredObject == null)
        {
            throw new TypeNotRegisteredException(string.Format(
                "The type {0} has not been registered", typeToResolve.Name));
        }
        return GetInstance(registeredObject);
    }

    private object GetInstance(RegisteredObject registeredObject)
    {
        if (registeredObject.Instance == null ||
            registeredObject.LifeCycle == LifeCycle.Transient)
        {
            var parameters = ResolveConstructorParameters(registeredObject);
            registeredObject.CreateInstance(parameters.ToArray());
        }
        return registeredObject.Instance;
    }

    private IEnumerable<object> ResolveConstructorParameters(RegisteredObject registeredObject)
    {
        var constructorInfo = registeredObject.ConcreteType.GetConstructors().First();
        foreach (var parameter in constructorInfo.GetParameters())
        {
            yield return ResolveObject(parameter.ParameterType);
        }
    }
}

The SimpleIocContainer class has two public operations: Register and Resolve.

Register is used to register a type with a corresponding concrete implementation. When type is registered, it is added to a list of registered objects.

Resolve is used to get an instance of a type from the container. Depending on the Lifecycle mode, a new instance is created each time the type is resolved (Transient), or only on the first request with the same instance passed back on subsequent requests (Singleton).

Before a type is instantiated, the container resolves the constructor parameters to ensure the object receives its dependencies. This is a recursive operation that ensures the entire object graph is instantiated.

If a type being resolved has not been registered, the container will throw a TypeNotRegisteredException.

Using the Simple IoC Container with ASP.NET MVC

Now I am going to demonstrate using the container by creating a basic order processing application using ASP.NET MVC.

First we create a custom controller factory called SimpleIocControllerFactory that derives from DefaultControllerFactory. Whenever a page is requested, ASP.NET calls GetControllerInstance to get an instance of the page controller. We can then pass back an instance of the controller resolved from our container.

public class SimpleIocControllerFactory : DefaultControllerFactory
{
    private readonly IContainer container;

    public SimpleIocControllerFactory(IContainer container)
    {
        this.container = container;
    }

    protected override IController GetControllerInstance(Type controllerType)
    {
        return container.Resolve(controllerType) as Controller;
    }
}

We now need to set SimpleIocControllerFactory as the current controller factory in the global Application_Start handler.

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        var container = new SimpleIocContainer();

        BootStrapper.Configure(container);

        ControllerBuilder.Current.SetControllerFactory(new SimpleIocControllerFactory(container));
    }
}

In order for the SimpleIocControllerFactory to resolve an instance of the OrderController, we need to register the OrderController with the container.

Here I have created a static Bootstrapper class for registering types with the container.

public static class BootStrapper
{
    public static void Configure(IContainer container)
    {
        container.Register<OrderController, OrderController>();
    }
}

The controllers do not contain state, therefore we can use the default singleton lifecycle to create an instance of the controller only once per request.

When we run the application, the OrderController should be resolved and the page will load.

It is worth noting that the controller factory should be the only place we need to explicitly resolve a type from the container. The controllers are top-level objects and all our other objects stem from these. Dependency Injection is used to resolve dependencies down the chain.

To place an order we need to make a call to OrderService from the controller. We inject a dependency to the order service by passing the IOrderService interface into the OrderController constructor.

public class OrderController : Controller
{
    private readonly IOrderService orderService;

    public OrderController(IOrderService orderService)
    {
        this.orderService = orderService;
    }

    public ActionResult Create(int productId)
    {
        int orderId = orderService.Create(new Order(productId));

        ViewData["OrderId"] = orderId;

        return View();
    }
}

When we build and run the application we should get an error: “The type IOrderService has not been registered”. This means the container has tried to resolve the dependency, but the type has not been registered with the container. So we need to register IOrderService and its concrete implementation, OrderService, with the container.

public static class BootStrapper
{
    public static void Configure(IContainer container)
    {
        container.Register<OrderController, OrderController>();
        container.Register<IOrderService, OrderService>();
    }
}

The OrderService in turn has a dependency on IOrderRepository which is responsible for inserting the order into a database.

public class OrderService : IOrderService
{
    private readonly IOrderRepository orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        this.orderRepository = orderRepository;
    }

    public int Create(Order order)
    {
        int orderId = orderRepository.Insert(order);
        return orderId;
    }
}

As the OrderService was resolved from the container, we simply need to register an implementation for IOrderRepository for OrderService to receive its dependency.

public static class BootStrapper
{
    public static void Configure(IContainer container)
    {
        container.Register<OrderController, OrderController>();
        container.Register<IOrderService, OrderService>();
        container.Register<IOrderRepository, OrderRepository>();
    }
}

Any further types are that required simply need to be registered with the container then passed as an argument on the constructor.

Most full-featured IoC containers support some form of auto-registration. This saves you from having do to a lot of one-to-one manual component mappings.

I hope I have demonstrated that IoC containers are not magic. They are in fact a simple concept that, when used correctly, can help to create flexible, loosely-coupled applications.

Using Behaviour-Driven Development with ASP.NET MVC – Part 2

In part one, I introduced the PlaylistShare project, created some initial user stories, defined the acceptance criteria and created a template for writing executable specifications. In this part, I am going to write some executable specs for viewing playlists and implement the behaviour to make them pass. You can download the source code at the end of this post.

There a couple of approaches you can take when writing specs for an ASP.NET MVC user interface. Either you can run them directly against the UI from inside a browser, using a tool such as WaitiN. Or, you can drop in just below the UI and run the specs against the controllers. I prefer running them against the controllers as they run much faster and are not susceptible to changes to the HTML elements. However, you may find some aspects are better specified using a UI testing tool, such as behaviour that relies heavily on client-side scripting, which the controllers know nothing about.

I will be starting with the executable specification template I created in part one:

namespace view_playlist_specs
{
    namespace scenario_of
    {
        public abstract class listener_views_playlists : Specification<PlaylistController>
        {
            protected override PlaylistController create_subject()
            {
                // Create the system under test
                return new PlaylistController();
            }
 
            protected void given_a_list_of_playlists()
            {
                // Establish a list of playlists
            }
        }
    }
 
    namespace viewing_a_list_of_playlists
    {
        [TestFixture]
        public class when_the_listener_views_the_playlists 
            : scenario_of.listener_views_playlists
        {
            protected override void setup_scenario()
            {
                // Arrange
                given_a_list_of_playlists();
            }
 
            protected override void execute_scenario()
            {
                // Act
            }
 
            [Test]
            public void should_display_a_list_of_playlists()
            {
                // Assert
            }
 
            [Test]
            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()
            {
                // Assert
            }
        }
    }
}

The first scenario we are going to implement is:

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Scenario 1: Viewing a list of playlists

Given a list of playlists

When the listener views the playlists

Then should display a list of playlists

  And playlists should be ordered by date submitted from newest to oldest

First, lets create a new ASP.NET MVC application and add a PlaylistController to give us a subject to work with.

[HandleError]
public class PlaylistController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

Now that we have a controller, let’s specify the first outcome of the scenario.

[Test]
public void should_display_a_list_of_playlists()
{
    the_view_model.should_be_equivalent_to(playlists);
}

The outcome states that a list of playlists should be viewed on the page.

the_view_model is a property on the spec base class that wraps calls to ProductsController.ViewData.Model. This makes the code slightly more readable. We can use ViewData.Model on the controller to pass data back to the view. In this case we want to pass back a list of Playlist objects.

You will notice I have used a method called should_be_equivalent_to to verify that the_view_model contains the same elements as playlists. This is an extension method defined in a SpecificationExtensions class I have added to the project. This class contains some helpful extension methods that wrap-up calls to NUnit assertions. This enables us to assert conditions directly on the objects, producing slightly more readable outcomes. Again, this is a personal preference and you can use ordinary Assert calls if you wish.

Running this spec should result in a failure, as we are not yet returning any playlists from the Index() controller method. We need to provide the controller with our list of playlists. To do this, we need to somehow pass a list of Playlist objects to the controller. The best way to do this is to use Dependency Injection and Mocking to pass a Repository containing our Playlist objects into the controller. Woah! Sounds complicated. But, it’s actually quite simple…

Let’s modify the PlaylistController to take an IPlaylistRepository and initialise a field in the constructor.

[HandleError]
public class PlaylistController : Controller
{
    private readonly IPlaylistRepository _playlistRepository;
 
    public PlaylistController(IPlaylistRepository playlistRepository)
    {
        _playlistRepository = playlistRepository;
    }
 
    public ActionResult Index()
    {
        return View();
    }
}

Now we need to pass an instance of this repository when we create the PlaylistController in our specs. To do this I am going to generate a stub using RhinoMocks. This creates a runtime implementation of the IPlaylistRespository that we can pass into the controller.

protected override void setup_scenario()
{
    playlist_repository = MockRepository.GenerateStub<IPlaylistRepository>();
}
 
protected override PlaylistController create_subject()
{
    return new PlaylistController(playlist_repository);
}

The setup_scenario method gets called right before create_subject, so we can use this to create any dependencies before the PlaylistController gets instantiated. Any scenarios can create additional context by overriding the setup_scenario method.

Now we need to add a GetAll() method to IPlaylistRepository that allows the PlaylistController to retrieve a list of Playlist objects.

public ActionResult Index()
{
    var playlists = _playlistRepository.GetAll();
    return View(playlists);
}

Back in our specs, we can now tell the stubbed playlist_repository to return some Playlist objects whenever the GetAll() method is called.

protected void given_a_list_of_playlists()
{
    playlists = new List<Playlist>
                    {
                        new Playlist(),
                        new Playlist(),
                        new Playlist()
                    };
    playlist_repository.Stub(r => r.GetAll()).Return(playlists.ToArray());
}

Our spec should now be passing! We have now confirmed the controller is passing a list of playlists to the view to display on the page.

So, let’s write an assertion for our next outcome: “playlists should be ordered by date submitted from newest to oldest”. Here we verify that the Playlist objects sent to the view are ordered by date-submitted in a descending order.

[Test]
public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()
{
    the_view_model.should_be_ordered_by_descending(p => p.DateSubmitted);
}

For this to compile we need to add a DateSubmitted property to the Playlist object.

I have created a helper method called should_be_ordered_by_descending that will verify that the playlists are ordered correctly. It’s really useful to create extension methods for complicated assertions to better explain what is being verified.

We can now make this spec pass by using LINQ to order the list of Playlist objects in the controller action before they are returned to the view.

public ActionResult Index()
{
    var playlists = _playlistRepository.GetAll();
    return View(playlists.OrderByDescending(p => p.DateSubmitted));
}

Here is the output from the Resharper test runner:

test-run-resharper-1-small

Using these naming conventions means that if a spec fails, it’s easy to identify what behaviour is causing the problem. You also get clear, concise, executable documentation that describes how your application behaves.

You might have noticed that I have been implementing the playlist controller without even running the web site. By implementing the controller first, we can focus on the core behaviour of the application without being concerned about how it is presented. In the next part, we will create the view that displays the playlists on the page.

Download the source code for Part 2

Using Behaviour-Driven Development with ASP.NET MVC – Part 1

Introduction

Welcome to the first post in a series where I hope to demonstrate creating an ASP.NET MVC application using Behaviour-Driven Development (BDD).

I agonised over how to introduce this blog post. In the end, I figured it would be best just to get straight into it! There are plenty of excellent articles that introduce the concepts behind both BDD and ASP.NET MVC, so I won’t bother repeating it here. I will explain core concepts along the way and provide links to further information. If you feel that I haven’t explained something properly, or have missed something, then please post a comment and I’ll try to elaborate further.

Right, let’s get started. The application I am going to build is a playlist sharing web site aptly called PlaylistShare (slightly unimaginative, but if you have a better name, let me know! :-). Music streaming services like Spotify are becoming increasingly popular and a number of sites have sprung up that allow you to share playlists with other people. I don’t intend this example to be anything unique or new, but I thought it would be an interesting subject and not yet-another-storefront example.

I will provide a link to download the source code at the end of each post. I have also created a Google Code project to host the source code.

It All Starts With a Story

BDD is an outside-in development process. We start by identifying goals and motivations, then drill down to the features that will achieve those goals. So, I’ve come up with a few user stories to get us started.

Story: Listener views playlists

As a playlist listener, I can view a list of playlists that have been submitted, so that I can find a playlist I might enjoy.

Story: Listener views playlist details

As a playlist listener, I can view the playlist details, so that I can get more information about the playlist.

Story: Contributor submits a playlist

As a playlist contributor, I can submit a playlist, so that others can listen to it.

There are a lot of other features I can add, but as a “business”, these are my top priorities and will allow me to get something functional delivered first.

Defining Acceptance Criteria

In order to determine what behaviour to implement, we need to create a list of acceptance criteria for each story. The acceptance criteria allows us to define when a story is “done”.

Note: this is a very important stage. It allows all members of the team to share a common understanding of what the system is meant to do. It is tempting to jump straight to writing the executable specifications, but this stage needs to be carefully considered and have input from the customer and testers.

We will define the acceptance criteria as example scenarios using a given/when/then vocabulary.

Story: Listener views playlists

Scenario 1: Viewing a list of playlists
Given a list of playlists
When the listener views the playlists
Then should display a list of playlists
  And playlists should be ordered by date submitted from newest to oldest

Story: Listener views playlist details

Scenario 1: Viewing playlist details
Given a playlist
When the listener views the playlist details
Then should display the playlist details
  And should display a link to listen to the playlist

Story: Contributor submits a playlist

Scenario 1: Submitting a playlist
Given a playlist
When the contributor submits the playlist
Then should submit the playlist
  And should display a message confirming the submission was successful

Scenario 2: Submitting a playlist without a name
Given a playlist without a name
When the contributor submits the playlist
Then should display a message saying the name is required
  And should not submit the playlist

Now that we have defined some acceptance criteria, we can create the executable specifications used to drive the implementation (a fancy way of saying, “write some tests!”). As we go forward we will probably identify other features we would like. We will make a note of these then add them to our next “iteration”.

Writing Executable Specifications

In BDD, tests are called specifications. This is mainly to get away from the notion that we are “testing”. Rather, we are defining behaviours that will drive the development process. We will still end up with a full suite of automated tests, but this is merely a very handy side-effect, not the goal, of BDD.

There are a number of BDD frameworks available for .NET, the most well-known of these being NBehave. However, these frameworks can be difficult to get started with and can distract us from the main purpose of BDD, which is to effectively describe the application behavior. This is not because these frameworks are bad, but is more to do with the constraints of the C# language. BDD frameworks are much more effective in languages like Ruby, where the syntax makes it very easy to write readable specifications using frameworks such as RSpec and Cucumber. For this example, I am going to stick with using NUnit and structure the test classes and member names to enable us to write BDD specifications. It will be a glorious day when when eventually see RSpec and Cucumber working on IronRuby and integrated seamlessly with our .NET applications. Until then, this is my current preference for writing BDD-style specifications in real-world applications.

I use a common Specification base-class to provide a framework for writing the specifications. This simple class contains the NUnit setup/teardown methods, handles exceptions and coordinates the various stages of executing a scenario.

These are a few conventions I use when writing BDD-style specifications:

  • Specification names are lowercase with underscores. This_is_to_make_the_specifications_more_readable. It is a personal preference, but I find PascalCaseNamingBecomesHardToReadForLongSentences (see what I did there… heh).
  • One test-fixture per scenario. Each test fixture represents a scenario of the story.
  • Each test-fixture is wrapped in a namespace that describes the scenario. This allows us to easily navigate the scenarios and prevents naming conflicts with other actions. This becomes important when we have the same action in different scenarios.
  • Each test-fixture name defines the action. An action is the “when” part of a scenario. It is the event that causes the behaviour.
  • Each test-fixture derives from a base class that describes the story. By inheriting from a base class, we can provide common set up data that is shared across all scenarios in the story. It also provides us with a handy reference back to the original story.
  • The context is set before executing the action. The context is the “given” part of a scenario. The context sets the state of the system-under-test and its dependencies before the action is invoked. Wrapping setup code in helper-methods makes it easy to see what context we are creating and to reuse common setup steps.
  • One test per outcome. An outcome is the result of an action, the “then” part of a scenario. We may have many outcomes from an action, but we should only be testing for one thing per outcome. So try to only make one assertion per test method. Test for other outcomes in separate test methods.

The outline for the first scenario looks like this:

namespace view_playlist_specs
{
    namespace scenario_of
    {
        public abstract class listener_views_playlists : Specification<PlaylistController>
        {
            protected override PlaylistController create_subject()
            {
                // Create the system under test
                return new PlaylistController();
            }
 
            protected void given_a_list_of_playlists()
            {
                // Establish a list of playlists
            }
        }
    }
 
    namespace viewing_a_list_of_playlists
    {
        [TestFixture]
        public class when_the_listener_views_the_playlists 
            : scenario_of.listener_views_playlists
        {
            protected override void setup_scenario()
            {
                // Arrange
                given_a_list_of_playlists();
            }
 
            protected override void execute_scenario()
            {
                // Act
            }
 
            [Test]
            public void should_display_a_list_of_playlists()
            {
                // Assert
            }
 
            [Test]
            public void playlists_should_be_ordered_by_date_submitted_from_newest_to_oldest()
            {
                // Assert
            }
        }
    }
}

Download the source code containing the outline for the first scenario.

I hope this has been a helpful way to get started. I will explain a lot more about writing specifications in upcoming posts. Please feel free to post any questions or comments. In the next part of this series, I will begin implementing a playlist controller and passing the scenarios.