Simplicity equals elegance

Introduction

I have recently had to solve a massive problem do with architecting a next generation platform for a commercial product that will steer the development team now and into the future. This task has a history of failure and now I have stepped up to try a make things right. Some of the problems I needed to address was:

  • Architecture (to SOA or not to SOA)
  • Technology
  • Migration plan
  • Deployment

Retrospective

While brainstorming ideas about how to solve my particular problems, I went through a period of reflection. I questioned my self on all the practices that I would promote and the ones I would discard. I found this to be very healthy. Any good developer/architecture should regularly question their motives and approaches.

A lot of what we do its based on opinions, and sometimes based on other peoples opinions. I went about  eliminating the opinions that were not by own. For example “Persistent arrogance”:

  • Is this just an idealism?
  • What benefit does it give me?
  • What do I lose if I don’t have it?
  • Is this something at sounds great in theory but in practice it not achievable?
  • Is this something that someone has promoted to make them sound clever?

I did this over and over till I was happy that I had opinions that were my own. I reviewed programming and the industry in general and reflected on my own previous experience. One of the lessons I learnt was, it does not matter how clever someone is, what technologies you know or what pretty pieces of paper you have. Simple is best.

Just because its a dirty job doesn’t mean you need to get dirty!

I also find that top class developers generally make things complex and perceive that it is simple. Its worth having less junior developers around and present your code to them and get their feedback. Another trait that senior developers do it try to design and develop an elegance system, this leads to complexity, complexity leads to confusion, confusion leads to failure. The right thing to do it design and develop a system to be simply, then you get elegance.

What is Simple

Simple is relative, how do you measure simple? This is measured at many levels. The common place would be at code level.

Source code

Many books have been written about writing “Good” (again relative) code and writing Quality (relative again) code. Their are many things that make code “better” which makes it “simple” to understand and maintain: For example: (I have thought of many more points but a couple will do to illustrate the point)

  • Name classes, methods and variables correctly and meaningful.
  • Write methods that are small and concise.
  • Follow the OO principles (SOLID).
  • Use TDD with Test first design.

The next view would be how your code is structured and layered. If you have complex system that is all tackled up and depends on things that it shouldn’t, may be a few god objects and is a big sticky ball of mud. Then stretch it like a rubber band, pull the code about and separator it by the context that its used in. Of course, if you have a big ball of mud then I am pretty certain that you won’t have any unit tests that give you the feedback needed while you refactor. If you, like me have been unlucky and come to work on a code base that is a ball of sh** mess, then master refactorings and design patterns.

Technology

  • Is the technology the right tool for the job?
  • Are you using this tool, cos its someone above you tells you to?
  • Do you have alternatives?
  • How easy is it to recruit people with this skill?
  • Its the technology you are using, just geeky and looks got on your CV?

Technology has a big part to play in simple/complex contest. Its worth reviewing what you are are using.

Architecture

Does the architecture guide you or does it constrain you. Do you have read a book to understand the architecture that you are using? if an architecture is not flexible and you need to read a book about it then is not simple and not right.

Trends and fashion

This is linked to technology and my retrospective stated above. Developers my nature enjoy learning new technologies. Developers also try to find new smarts for the way they work. This is all great, but does need to be managed, otherwise your code base will be littered with spikes and random technologies. Before long your developers will not know what the standard tools or right the processes are. Technology and processes are in and out of fashion very quickly. A big dollop of common sense is required, review technologies and process in isolation and actually use the technology and try out a process rather than reading some blog and believing it.

Its easier to understand what is not simple.

Make it simple

“Simple” does have some concrete measures but their are other measures that are unique to you and your team. You need to identify what is important to you and analyse your code to see how it scores.  Making things simple it in my opinion, the most important design goal.

A point about Design patterns

I have heard people slate design patterns, i personally i love them, but some/alot of people misuse them and thats whats has started the negative press. The rule with design patterns to identify a pattern in the code not to put a patterns in the code that don’t fit. I find the power of patterns is the vocabulary. Its great describe a class’s purpose in life when stating its responsibility, for example “its an adapter” or “its a factory”. All things in moderation.

Conclusion

Keep it Simple. A easy principle to understand, but often the hardest to implement because out actions are to learn bigger more complex technologies and processes that keep pushing our careers to supposed new heights. It doesn’t matter how big someone’s brain is, can you develop code that is simple?

Advertisements

ASP.NET MVC – Creating an application with a defined architecture

Introduction

This post continues from this previous post. In this post I will be creating a ASP.NET MVC application using the architecture described in the previous post. I will start by laying out the requirements, driving out the behaviour through tests, implement Unity and create the layers for the UI, controller and Presentation Processes.

Since writing my previous post, I have came across a blog which contains some really good tips / best practices for ASP.NET MVC, which I recommend you read.

http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx

http://weblogs.asp.net/rashid/archive/2009/04/03/asp-net-mvc-best-practices-part-2.aspx

Requirements

So to start, we need requirements as development should be driven by requirements. In business analyst language, this is the requirement that i will be working against.

  1. As a user when browsing the customer feature within the application I expect to see a list of customers, each customer will contain the following information:
    • Customer name
    • Account number
    • Account Manager
    • City
    • Country

Where to start

ASP.NET MVC is focused around controllers and actions. So its a natural place to start describing how you implement this architecture. On a day to day basic, I write tests first that drive out the behaviour. As my application grows, my layers become cemented. The name of classes denote the responsibility and context.

Creating the Project

I am starting with a new “Asp.Net MVC web application” project called “Web” and a test project called “Web.Specs”. My references are:

Web application

Test Project

  • NUnit – “nunit.framework.dll”.
  • NBehave (using NSpec only) – “NBehave.Spec.NUnit.dll”.
  • Rhino Mocks – “Rhino.Mock.dll”.
  • MVCContrib – “MvcContrib.TestHelper.dll” and “MvcContrib.dll”.

Test first

Here is the test for the requirement defined above, putting the controller under test.

using System.Collections.Generic;
using System.Web.Mvc;
using MvcContrib.TestHelper;
using NBehave.Spec.NUnit;
using NUnit.Framework;
using Rhino.Mocks;
using Web.Controllers;
using Web.PresentationProcesses.Customers;

namespace Web.Specs
{
    [TestFixture]
    public class Browsing_a_list_of_customers
    {
        private CustomerController controller;
        private ICustomerAgent customerAgent;

        [SetUp]
        public void Setup()
        {
            customerAgent = MockRepository.GenerateStub<ICustomerAgent>();
            controller = new TestControllerBuilder()
                        .CreateController<CustomerController>(new object[] { customerAgent });
        }

        [Test]
        public void Should_pass_a_list_of_customers_to_the_view()
        {
            var customers = new List<Customer>();

            customerAgent.Expect(x => x.GetCustomerList()).Return(customers);

            ViewResult result = controller.List();

            result.ShouldNotBeNull();
            result.AssertViewRendered().ForView(CustomerController.ListViewName);

            customerAgent.AssertWasCalled(x => x.GetCustomerList());
        }
    }
}

This test has driven out the “CustomerController”, an interface called “ICustomerAgent” and two objects called “Customer” and “CustomerListViewModel”.

I have created another class library called “Web.PresentationProcesses” which doesn’t have any additional references. I have placed the Customer, CustomerListViewModel and the ICustomerAgent interface under a new folder called “Customers” in the Web.PresentationProcesses assembly.

The code created so far is:

//Customer.cs

namespace Web.PresentationProcesses.Customers
{
    public class Customer
    {
        public string Name { get; set; }
        public string AccountNumber { get; set; }
        public string AccountManagerName { get; set; }
        public string City { get; set; }
        public string Country { get; set;}
    }
}

//CustomerListViewModel.cs

using System.Collections.Generic;

namespace Web.PresentationProcesses.Customers
{
    public class CustomerListViewModel
    {
        public List<Customer> Customers { get; set; }
    }
}

//ICustomerAgent.cs
using System.Collections.Generic;

namespace Web.PresentationProcesses.Customers
{
    public interface ICustomerAgent
    {
        List<Customer> GetCustomerList();
    }
}

//CustomerController.cs
using System.Web.Mvc;
using Web.PresentationProcesses.Customers;

namespace Web.Controllers
{
    public class CustomerController : Controller
    {
        private readonly ICustomerAgent customerAgent;

        public const string ListViewName = "List";

        public CustomerController(ICustomerAgent customerAgent)
        {
            this.customerAgent = customerAgent;
        }

        public ViewResult List()
        {
            var viewModel = new CustomerListViewModel
            {
                Customers = customerAgent.GetCustomerList()
            };

            return View(ListViewName, viewModel);
        }
    }
}

At this point the solution looks like this:

AspNetMvcBlogSolution

At the moment, the unit test will pass but if you run the application it will be broken because we don’t have a view and the customer controller doesn’t have a default constructor.

Creating the View

  1. Create a new folder called “Customer” inside the “Views” folder
  2. In the newly created folder, create a strongly typed view called “List” using the type “CustomerListViewModel”.
  3. Open up the site.master view. In the “menucontainer/menu” div, add the following under the link to the “Home/About” page.
    <li><%= Html.ActionLink("List", "List", "Customer")%></li>
  4. Add the following to the List view.
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<Web.PresentationProcesses.Customers.CustomerListViewModel>" %>

<%@ Import Namespace="MvcContrib" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
	<title>Customer List</title>
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Customer List</h2>

    <table cellpadding="1" cellspacing="0" border="1">
        <thead>
            <tr>
                <th>Name:</th>
                <th>Account Number:</th>
                <th>Account Manager:</th>
                <th>City:</th>
                <th>Country:</th>
            </tr>
        </thead>

        <tbody>
            <% Model.Customers.ForEach(customer => { %>
		<tr>
                <td><%= customer.Name %></td>
                <td><%= customer.AccountNumber %></td>
                <td><%= customer.AccountManagerName %></td>
                <td><%= customer.City %></td>
                <td><%= customer.Country%></td>
		</tr>
            <% }); %>
        </tbody>
    </table>
</asp:Content>

The next stage is to have an IOC container resolve the dependencies for as at runtime.

Implementing Inversion of Control

Inversion of control / dependency injection has become very popular over the last couple of years and is a great practice to use. Their are a quite a few containers on the market at the moment, all are very good and apart from the common functionality that they all share. Some of the containers have unique qualities. I have mainly use Castle Windsor, Unity and Ninject. My personal favourite is Ninject because it has a simple fluent interface and contextual binding. At work we are using Unity mainly because its from Microsoft, but we do have applications that use Castle Windsor and Spring.net. I find that once you know one container its really ease to use another. Some of my fellow developers and I do experiment with different containers, although it doesn’t take long to swop them, using the Common Service Locator will make thing easier.

But before i start registering types, I common anti pattern that i have seen is that the container is defined in the web application being at the top of layer stack and then references all of the layers below it so it can add the types to the container. The solution to this is to pass via interface the container reference to each layer and allow a each layer to register its types.

  1. Starting from the top in the web application, new up the container and register the types that are in the web application only like the controllers.
  2. Then from the web application, pass the container reference to the PresentationProcesses layer via an interface. The PresentationProcesses assembly will expose a module object that accepts the container reference.
  3. The module in the PresentationProcesses layer will register its types and then could pass the container reference to the layer below it. If you are using WCF services to expose your service layer then the chain stops here. If your application doesn’t have external services and runs in-process then this pattern continues going down the layer stack.

Some IOC containers allow you to register types in config, code or both. Although i don’t like config anyway, using config to register types can cause problems. Typically when you are refactoring code, like renaming or moving types into other namespaces, that you miss out changing the config files. This results in exceptions at runtime.

I am going to stick with using Unity here and I am going to reference the unity assemblies and use MVCContrib unity assembly:

  • Microsoft.Practices.Unity.dll
  • Microsoft.Practices.ObjectBuilder2.dll
  • MvcContrib.Unity.dll

The best place to get the container created and configured is from within Application object in the Global.asax. If you have used MonoRail and Castle Windsor together then this has the same usage pattern.

using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Microsoft.Practices.Unity;
using MvcContrib.Unity;

namespace Web
{
    public class MvcApplication : HttpApplication, IUnityContainerAccessor
    {
        private static UnityContainer container;

        public static IUnityContainer Container
        {
            get { return container; }
        }

        IUnityContainer IUnityContainerAccessor.Container
        {
            get { return Container; }
        }

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

            ConfigureContainer();
        }

        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute("Default", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = "" });
        }

        private void ConfigureContainer()
        {
            if (container == null)
            {
                container = new UnityContainer();

                new PresentationProcesses.PresentationProcessesModule().Configure(container);

                ControllerBuilder.Current.SetControllerFactory(typeof(UnityControllerFactory));
            }
        }
    }
}

Creating the Agent

The next step to create a concrete class that implements the ICustomerAgent interface called “CustomerAgent”. We didn’t need to make it do any at the moment as we are still trying to get the application working at runtime. Plus when we do start making the “CustomerAgent” do something we will drive it from a test first. We will create this class next to where the interface lives.

using System;
using System.Collections.Generic;

namespace Web.PresentationProcesses.Customers
{
    public class CustomerAgent : ICustomerAgent
    {
        public List<Customer> GetCustomerList()
        {
            throw new NotImplementedException();
        }
    }
}

I have created another class assembly called “Web.Container.Interfaces” which contains just one interface called “IModule” which looks like this.

using Microsoft.Practices.Unity;

namespace Web.Container.Interfaces
{
    public interface IModule
    {
        void Configure(IUnityContainer container);
    }
}

This class assembly only references Unity and will be referenced by other assemblies like “PresentationProcesses”.

Now to create the PresentationProcessesModule.

using Microsoft.Practices.Unity;
using Web.Container.Interfaces;
using Web.PresentationProcesses.Customers;

namespace Web.PresentationProcesses
{
    public class PresentationProcessesModule : IModule
    {
        public void Configure(IUnityContainer container)
        {
            container.RegisterType<ICustomerAgent, CustomerAgent>();
        }
    }
}

Now to run the app, and now when you click the “list” link on the home page, you should get an “The method or operation is not implemented.” exception page, which is expected at this time. What this does prove it that the IoC is working correctly.

The next stage in this process would be drive out getting some real data from somewhere and will get returned from the CustomerAgent. Which is going to be in my follow on post, but for now we can simply new up a collection with some new’d up customer objects as shown below.

using System.Collections.Generic;

namespace Web.PresentationProcesses.Customers
{
    public class CustomerAgent : ICustomerAgent
    {
        public List<Customer> GetCustomerList()
        {
            return new List<Customer>
            {
                new Customer
                {
                    Name = "company1",
                    AccountNumber = "12345",
                    AccountManagerName = "mr account manager1",
                    City = "Some Town",
                    Country = "England"
                },
                new Customer
                {
                    Name = "company2",
                    AccountNumber = "54321",
                    AccountManagerName = "mr account manager2",
                    City = "Some other place",
                    Country = "England"
                },
            };
        }
    }
}

Run the app

Now when you run the application, click on the “list” link in the menu. You should now get this following page.

listView

Moving on

What we have got is an ASP.NET MVC that has unity in place to resolve types at runtime. We have types (customer and customer ViewModel) defined in the presentation processes layer that the view are bound to. The customer agent returns instances of these types.

The next steps will be to change the Customer agent to get the data from somewhere.  This will be driven out via tests. This is going to be the focus on my next post.

ASP.NET MVC – Defining an application architecture

Introduction

ASP.NET MVC is creating some buzz at the moment and has been long awaited. Being a Microsoft product, MVC will be launched into the mainstream development arena and like webforms, could and hopefully will be a popular web development platform that will be around for years to come . Microsoft and some of the key players in this technology and has already got a good community going. The official ASP.NET MVC site contains some very light and quick code tutorials to illustrate the features of MVC.

Although this is all good, I do have some concerns. It starts with what developers learn, the tutorials on the official asp.net mvc site are aimed at developers at different levels and are for illustration only. They are not samples of production quality code. What is missing at the moment are the better practice and guidelines for developing line of business application which I am sure 99% of applications developed with ASP.NET MVC are going to be for.

Separating concerns

On the official ASP.NET MVC site, you will find code examples that are directly fetching data using linq for entities with linq queries directly in the controllers. Its not the responsibility of the controller to fetch data in this manor, their is at least a layer or two missing between controller and data access. My concern is that we will end up with same situation that is present in webforms where applications could be developed with most of the application logic ending up in the controllers (like code behind in webforms).  ASP.NET MVC already is enforcing the separation of concerns for the view but not the controller and model. This is where the design focus is needed.

Layers and tiers

Layering software is probably one of the most basic concepts in the software development that I think is under estimated. I have seen on various projects in the past that its easy to get wrong with either too few or to many layers. I find that logical layers can be defined by separating out the concerns at a high level.

A layer is a logical grouping of code that have a common concern. A tier is typically a physical boundary like a server or client PC. A tier will contain at least one or more layers. Layers that are designed to run in the same tier typically communicate in a finely grained manor (chatty interface) where commutating across tiers should be coarse grain (chunky interface). 

You must either be new to software development have lived in a cave or something if you have not heard of n-tier architecture.  I mention tiers here because i one of the principles that is usually forgotten about in that, when communicating across tiers, do so in a coarse grain mannor.

High above the ground

The architecture that I am defining is nothing new, its a very common scenario using some Domain Driven Design concepts. An alternative variant of this architecture is an SOA implementation. The SOA variant would be the right choice an enterprise level application. The simpler variant of this architecture can be migrated to the SOA variant.

Conceptual logical layers (simple variant)

conceptual logically layers

UI tier – This is the end users computer which will access your application via an internet browser. So the user interface layer will contain (x)html and CSS. Plus this layer could contain JavaScript, silverlight, Flex etc.

Presentation tier – In this tier, you have two layers, the controller and presentation processes. The controller layer will be invoked by the ASP.NET MVC framework in response to an http request. Your controller should do nothing more than delegate any processing to logic in the Presentation Processes layer. The Presentation Processes layer will typically request information from the service layer and process the service response by mapping the information to an object that both Presentation Processes and the controller layer know about. One of the benefits that this gives, is that you could develop your application that is decoupled from the service layer.

Business tier – This tier is very flexible in its implementation. In its most simplest form, it could be run in process on web server that will actually remove the physically boundary between the business and presentation tiers. For enterprise level implementations, this tier could be made up my many separate applications that could be distributed across many application servers. Regardless of the physically boundary, the Server layer should be thin as logic goes. The service layer provides an API to consumers. Beneath the service layer you have the domain layer that contains the business logic and represents the business model. The repository layer is bridge between your application logic and data persistence.

Persistence tier – Does what it says on the tin, this would typically be your database server(s). 

SOA variant

 

Here is the conceptual logically layers using an SOA approach.

image

The key difference here is that the service layer is broken up into multiple services that provide a distinct function. SOA is a massive subject that i would not do it any justice trying to sell it, but using this approach gives you many benefits that the development investment is worth it.  If you are have your business tier running out of process or on different services then WCF is the right technology for the job.

Although I have used ASP.NET MVC in the title of this post, this architecture is relevant for most technology implementations. Everything below the controller layer is plain .net code that you could put any .net view technology at the top of this architecture.

Architectural Rules

Rules are needed for any architecture, these are the common rules that I like to stick to.

  • A layer can only see what is beneath it, never above it.
  • A layer must only see the layer directly below it and not the layers further down the layer stack.
  • Use message objects to communicate between layers that are across tiers (although, using message objects between any layer is also good).
  • Limit your cross cutting concerns. (logging and security are typical candidates as a cross cutting concern. Loads of utilities classes/assemblies are not).
  • Strive for low coupling – By enforcing a layer policy where you can only see the direct below helps here. Using interfaces that your concrete classes implement gives you a recipe of low coupling as with so many other benefits.
  • No leaky abstractions.

Next steps

At this point while writing this post, i started to create an ASP.NET MVC application using this architecture. This post was starting to get to big so i have split it up. Here is the next post to continue on this topic.

db4o Most Valued Professional

I have today been selected as a db40 Most Valued Professional (DVP)  of which  I am flattered. I am flattered that other people have selected me for this. db4o has a massive community and following and its great being part of it.I am amongst approximatly 150 other DVP’s around the world which at the moment makes me feel a bit special.  This recognition from the industry is going to  drive and motivate me more to keep learning new techniques, acquire new skills and share them with anyone who takes time to read my posts.

http://developer.db4o.com/dvp/

ASP.NET MVC: A utility for testing secured Actions

I have come across a common scenario while developing an ASP.NET MVC application. This being testing Actions that require the user to be authorised and / or requires permissions to execute methods  that are locked down with principal permissions.

Here as an example of a controller with an action that is firstly decorated with the “Authorize” attribute (ASP.NET MVC filter) that requires the user to be in a specified role.

[Authorize(Roles="Client Administrators")]
public ViewResult Edit(int clientId)
{
    return View("Edit");
}

 

While I was writing a test for an Action that needed the user to be Authorized . I   created implementations of the IIdentity and IPrincipal interfaces that I could use to satisfy this requirement. Although this worked, it was not reusable. When you set principle, you should apply it to the current AppDomain instead of the current thread as the every thread created in your AppDomain will have the principal set automatically. Once you have set the principle you cannot apply my than once as it will throw an exception. It is also a problem is you try to reset the principal to null.

To add to matters, is was not long before I needed to satisfy principal permissions. My Principal and Identity implementations needed to be more flexible.

So the answer was to create a utility that firstly set the AppDomain to use my principal implementation and allow each and every test to arrange the state of the principal. For each and every test  I also want to write the minimum amount of code by only writing one line of code.  This line of code would be amongst NBehave and RhinoMocks code that have their own fluent interfaces so I want my line of code to fit in with the fluent style. Below are three ways I want to my utility.

//1
TheCurrentUser.Instance.IsAuthenticated().And.IsInAllRoles();
 
//2
TheCurrentUser.Instance.IsAuthenticated()
    .And.IsInThisRole("System admins")
    .And.IsInThisRole("developers")
    .And.IsInThisRole("power users");
 
//3
TheCurrentUser.Instance.IsNotAuthenticated();

 

So I started to create this utility by placing its into its own assembly. The root object is the “TheCurrentUser” object. Its the only public class in the assembly and is used as  a singleton. It creates and hosts three objects references and sets the IPrincipal implementation to the current AppDomain.

using System;
using System.Security.Principal;
 
namespace RussellEast.Principal.Utility
{
    public class TheCurrentUser
    {
        static readonly TheCurrentUser instance = new TheCurrentUser();
 
        private IPrincipal principal;
        private IAuthenticationOptions options;
        private ISecurityContext context;
 
        private TheCurrentUser()
        {
            BuildObjectGraph();
            SetAppDomainPrincipal();
        }
 
        static TheCurrentUser() { }
 
        public static IAuthenticationOptions Instance
        {
            get { return instance.Options; }
        }
 
        public IAuthenticationOptions Options
        {
            get { return options; }
        }
 
        private void BuildObjectGraph()
        {
            context = new SecurityContext();
            principal = new FakePrincipal(context);
 
            options = AuthenticationOptions.Create(context);
        }
 
        private void SetAppDomainPrincipal()
        {
            AppDomain.CurrentDomain.SetThreadPrincipal(principal);
        }
    }
}

 

The fluent interface uses a context object (that holds the state as its passed around) that is injected into  various objects that are explained below. The context object implements the following interface.

using System.Collections.Generic;
 
namespace RussellEast.Principal.Utility
{
    internal interface ISecurityContext
    {
        bool IsAuthenticated { get; set; }
        bool IsInAllRoles { get; set; }
        List<string> Roles { get; set; }
        void Reset();
    }
}

 

This is the concrete implementation of the ISecurityContext interface.

using System.Collections.Generic;
 
namespace RussellEast.Principal.Utility
{
    class SecurityContext : ISecurityContext
    {
        public bool IsAuthenticated { get; set; }
        public bool IsInAllRoles { get; set; }
        public List<string> Roles { get; set; }
 
        public void Reset()
        {
            IsAuthenticated = false;
            IsInAllRoles = false;
 
            if (Roles != null)
            {
                Roles.Clear();
            }
        }
    }
}

 

Back to the “TheCurrentUser” object, the instance property returns an object that implements the following interface below.

(Although this object is a singleton, the pattern would be to return the singular  instance of the singleton, i have not done this as the singleton does nothing but host objects and be the root object for the fluent interface.)

namespace RussellEast.Principal.Utility
{
    public interface IAuthenticationOptions
    {
        IAuthorisationRouter IsAuthenticated();
        void IsNotAuthenticated();
    }
}

 

My concrete of the above  interface is as follows:

namespace RussellEast.Principal.Utility
{
    class AuthenticationOptions : IAuthenticationOptions
    {
        private readonly IAuthorisationRouter router;
        private readonly ISecurityContext context;
        private AuthenticationOptions(ISecurityContext context, IAuthorisationRouter router)
        {
            this.context = context;
            this.router = router;
        }
 
        public IAuthorisationRouter IsAuthenticated()
        {
            ChangeSecurityState(true);
 
            return router;
        }
 
        public void IsNotAuthenticated()
        {
            ChangeSecurityState(false);
        }
 
        private void ChangeSecurityState(bool isAuthenticated)
        {
            context.Reset();
 
            context.IsAuthenticated = isAuthenticated;
        }
 
        public static IAuthenticationOptions Create(ISecurityContext context)
        {
            var roleAuthorisation = new RoleAuthorisation(context);
            var router = new AuthorisationRouter(roleAuthorisation);
 
            return new AuthenticationOptions(context, router);
        }
    }
}

 

As you can see from the code, the AuthenticationOptions class is passed an instance of the security context and an instance of the IAuthorisationRouter.

The responsibility of this class is to reset the context and set a new authentication value. This class also contains a “Factory Method” that is used to create an instance of this object.

The “IsAuthenticated” method returns the next link in the method chain being the “IAuthorisationRouter”.

namespace RussellEast.Principal.Utility
{
    public interface IAuthorisationRouter
    {
        IRoleAuthorisation And { get; }
    }
}

 

The “IAuthorisationRouter” purpose in life is to provide a linkage in the method chain. Here is the concrete implementation.

namespace RussellEast.Principal.Utility
{
    class AuthorisationRouter : IAuthorisationRouter
    {
        private IRoleAuthorisationController roleAuthorisation;
 
        public AuthorisationRouter(IRoleAuthorisationController roleAuthorisation)
        {
            this.roleAuthorisation = roleAuthorisation;
            this.roleAuthorisation.Router = this;
        }
 
        public IRoleAuthorisation And
        {
            get { return roleAuthorisation; }
        }
    }
}

 

I am using constructor injection as much as possible. It was not so clear cut with this object as the AuthorisationRouter exposes an instance of “RoleAuthorisation” which implies that it has knowledge of it. The “RoleAuthorisation” exposes an instance of the AuthorisationRouter. So both need to know about each other.  I am using interfaces to define the overall fluent interface so I want to keep it clean from any implementation that is needed to wire references to together. So the solution is to create another interface that is only used by a specific consumer  (Interface Segregation Principal). Because I need two instances of different objects that need to know about each other, I have to construct one object first that then inject that into the other object when its be instantiated. Then I use a setter (setter injection) to provide the reference of the second object back to the first object.

namespace RussellEast.Principal.Utility
{
    internal interface IRoleAuthorisationController :
        IRoleAuthorisation, ISettableRouter
    {
    }
}

 

Here is the “ISettableRouter” interface:

namespace RussellEast.Principal.Utility
{
    internal interface ISettableRouter
    {
        IAuthorisationRouter Router { set; }
    }
}

 

Here is the “IRoleAuthorisation” interface.

namespace RussellEast.Principal.Utility
{
    public interface IRoleAuthorisation
    {
        void IsInAllRoles();
        IAuthorisationRouter IsInThisRole(string role);
    }
}

 

I have a concrete class “RoleAuthorisation” that implements the “IRoleAuthorisationController” interface. Its responsibility is to manage the list of roles.

using System.Collections.Generic;
 
namespace RussellEast.Principal.Utility
{
    class RoleAuthorisation : IRoleAuthorisationController
    {
        private IAuthorisationRouter router;
        private readonly ISecurityContext context;
 
        public RoleAuthorisation(ISecurityContext context)
        {
            this.context = context;
        }
 
        public IAuthorisationRouter Router
        {
            set { router = value;  }
        }
 
        public void IsInAllRoles()
        {
            context.IsInAllRoles = true;
        }
 
        public IAuthorisationRouter IsInThisRole(string role)
        {
            if (!string.IsNullOrEmpty(role))
            {
                if (context.Roles == null)
                {
                    context.Roles = new List<string>();
                }
 
                if (!context.Roles.Contains(role))
                {
                    context.Roles.Add(role);
                }
            }
 
            return router;
        }
    }
}

 

That’s all the interfaces and classes needed to build the fluent interface. The last objects needed is the Principal and Identity objects, which reads its values from the context.

using System.Security.Principal;
 
namespace RussellEast.Principal.Utility
{
    class FakePrincipal : GenericPrincipal
    {
        private readonly ISecurityContext context;
 
        public FakePrincipal(ISecurityContext context) : base(new FakeIdentity(context), null)
        {
            this.context = context;
        }
 
        public override bool IsInRole(string role)
        {
            if (context.IsAuthenticated)
            {
                return context.IsInAllRoles ? true : context.Roles.Contains(role);
            }
 
            return false;
        }
 
        class FakeIdentity : GenericIdentity
        {
            private readonly ISecurityContext context;
 
            public FakeIdentity(ISecurityContext context) : base("Fake user")
            {
                this.context = context;
            }
 
            public override bool IsAuthenticated
            {
                get { return context.IsAuthenticated; }
            }
         }
    }
}

 

Although a lot of code is written for the fluent interface which took two hours to build from scratch, I have a very flexible utility that I know I am going to use a lot and not just with ASP.NET MVC. The only refactoring that I want to perform is to change the name of some of the interfaces as I feel that they could be better described. To finish this post, here is an example using this utility in a unit test.

 

 
        [Specification]
        public void Should_be_able_to_edit_a_client()
        {
            ViewResult result = null;
 
            story.WithScenario("editing a client")
                .Given("an instance of the controller", () => controller.ShouldNotBeNull())
                .And("the current user belongs to the 'client administrators' role", () =>
                {
                    TheCurrentUser.Instance.IsAuthenticated()
                        .And.IsInThisRole("Client Administrators");
 
                    //NOTE: these two lines are not needed, just  validating the utility.
                    Thread.CurrentPrincipal.Identity.IsAuthenticated.ShouldBeTrue();
                    Thread.CurrentPrincipal.IsInRole("Client Administrators").ShouldBeTrue();
                })
                .When("the Edit action is invoked", () =>
                {
                    result = controller.Edit(1) as ViewResult;
                })
                .Then("verify that the user is directed to the right view", () =>
                {
                    result.AssertViewRendered().ForView("Edit");
                });
 
        }

 

For a better understanding of the unit test above, please read this post

TDD/BDD with ASP.NET MVC

I have recently been going hammer and tongs with ASP.NET MVC. One of the selling points for ASP.NET MVC is its testability, so while I have been learning this technology, I have found a couple of annoyances.

When you create a new ASP.NET MVC project, the wizard in VS2008 asks you if you want to create a test project. If you do create the test project, you get a couple of pre made tests that really don’t portray good TDD and because you only get a couple of tests, you have low code coverage and have untested code. I have had to back peddle  tests for the existing code.

For doing any development with ASP.NET MVC, the MvcContrib project is an absolute must. The MvcContrib project contains general features that really improve your development, Dependency Injection, type safety, a Grid and much more. I found that the MvcContrib examples, are so straight forward that in 60 seconds of eyeballing the code I could understand it fully.

Keeping to the subject, MvcContrib provides a library that really help when it comes to testing. I have been developing with MonoRail fairly solidly for the last 6 months or so and their are similarities between the Castle test classes and the Library from MvcContrib.

To make things more real world:

  • My project is using Unity for its IoC container and I am injecting dependancies into my controllers (again the MvcContrib provides libraries that make this easy to implement). 
  • For writing my tests/specs, I am using NBehave, NUnit and RhinoMocks 3.5. 

I started rewriting the tests for the HomeController because is was the easiest. The tests check that the controller displays the right view.

using System.Web.Mvc;
using RussellEast.Mvc.Controllers;
using MvcContrib.TestHelper;
using NBehave.Narrator.Framework;
using NBehave.Spec.NUnit;
using NUnit.Framework;
using Specification = NUnit.Framework.TestAttribute;

namespace RussellEast.Mvc.Tests.Controllers.Home
{
    [TestFixture]
    public class When_displaying_home_pages : SpecBase
    {
        private HomeController controller;
        private Story story;
        private TestControllerBuilder builder;

        [Story]
        public override void MainSetup()
        {
            base.MainSetup();

            story = new Story("Home page");

            story.AsA("user")
                .IWant("to go to the home page")
                .SoThat("i can start using the application");

            PrepareController();
        }

        private void PrepareController()
        {
            builder = new TestControllerBuilder();

            controller = builder.CreateController();
        }

        [Specification]
        public void Index()
        {
            ActionResult result = null;

            story.WithScenario("home index page")
                .Given("the controller has been prepared", () => controller.ShouldNotBeNull())
                .When("the user navigates to the index view", () => result = controller.Index())
                .Then("verify that the result is correct", () => result.AssertViewRendered().ForView("Index"));
        }

        [Specification]
        public void About()
        {
            ActionResult result = null;

            story.WithScenario("about page")
                .Given("the controller has been prepared", () => controller.ShouldNotBeNull())
                .When("the user navigates to the about view", () => result = controller.About())
                .Then("verify that the result is correct", () => result.AssertViewRendered().ForView("About"));
        }
    }
}

The controller code is:

 

    public class HomeController : Controller
    {
        [Authorize, DefaultAction]
        public ActionResult Index()
        {
            ViewData["Title"] = "Home Page";
            ViewData["Message"] = "Sample text being displayed";

            return View("Index");
        }

        public ActionResult About()
        {
            ViewData["Title"] = "About Page";

            return View("About");
        }
    }

Note: to order for the above tests to pass, you need to supply the name of the view to render.

The tests above cover the behaviours for the HomeController which are very basic, so to raise the bar. The ASP.NET MVC project template comes with an AccountController that works with a membership provider and Forms Authentication. The controller has a constructor that accepts two parameters. Because the “System under test” is the Account Controller i am going to stub the dependencies and write tests for the “Login” and  “Logout” actions.

 

using System.Web.Mvc;
using System.Web.Security;
using RussellEast.Mvc.Controllers;
using MvcContrib.TestHelper;
using NBehave.Narrator.Framework;
using NBehave.Spec.NUnit;
using NUnit.Framework;
using Rhino.Mocks;
using Specification = NUnit.Framework.TestAttribute;

namespace EWS.Steeple.Tests.Controllers.Authentication
{
    [TestFixture]
    public class When_authenticating : SpecBase
    {
        private AccountController controller;
        private IFormsAuthentication formsAuthentication;
        private MembershipProvider membershipProvider;

        private Story story;

	[Story]
        public override void MainSetup()
        {
            base.MainSetup();

            story = new Story("Authenticating");

            story.AsA("known user to the system")
                .IWant("to be authenticated")
                .SoThat("i can use the system");

            PrepareController();
        }

        private void PrepareController()
        {
            TestControllerBuilder builder = new TestControllerBuilder();

            formsAuthentication = MockRepository.GenerateStub();
            membershipProvider = MockRepository.GenerateStub();

            controller = builder.CreateController(new object[] {formsAuthentication, membershipProvider});
        }

        [Specification]
        public void Should_log_in_with_user_name_and_password_while_not_caching_details()
        {
            string username = string.Empty;
            string password = string.Empty;
            bool rememberMe = false;

            ActionResult result = null;

            story.WithScenario("log in with validate details")
                .Given("a controller instance", ()=> controller.ShouldNotBeNull())
                .And("a user name", () => username = "Username")
                .And("a password", () => password = "password")
                .When("i attempt to log in", () =>
                {
                    membershipProvider.Expect(x => x.ValidateUser(username, password)).Return(true);
                    formsAuthentication.Expect(x => x.SetAuthCookie(username, rememberMe));

                    result = controller.Login(username, password, rememberMe, string.Empty);
                })
                .Then("redirect user to the home page", () =>
                {
                    result.AssertActionRedirect().ToAction(x => x.Index());

                    formsAuthentication.VerifyAllExpectations();
                    membershipProvider.VerifyAllExpectations();
                });
        }

        [Specification]
        public void Should_sign_out_and_return_to_login_when_logging_out()
        {
            ActionResult result = null;

            story.WithScenario("log out and return to login view")
                .Given("a controller instance", () => controller.ShouldNotBeNull())
                .When("i log out", () =>
                {
                    formsAuthentication.Expect(x => x.SignOut());

                    result = controller.Logout();
                })
                .Then("i expect to be sent to the login view", () =>
                {
                    result.AssertActionRedirect().ToAction("Login");

                    formsAuthentication.AssertWasCalled(x => x.SignOut());
                });
        }
    }
}

Some points to be aware of.

  • I have used two different ways to test the ActionResult was a redirect. The first and my preferred way is using the generic controller type and the lambda expression. I have been forced to use the string argument approach due to the fact that the “Login” action is overloaded. It complained when trying to use a lambda approach.;-(.
  • MvcContrib test library provides a “TestControllerBuilder” that not only creates that instance of the controller, but mocks out the HttpContext, Sessions and form data. The docs for MvcContrib explains all. I have used this in my “PrepareController” method. 
  • The default code in the AccountController has not been changed to suit these tests.

Creating Fluent finders and repositories part 1

Introduction

This is the first post of this series about implementing fluent finders and repositories, I am going to expand my current repository and finder implementation which is explained here. I recommend that you read this post (precursor) as this series continues on from this post and the code examples.

The objectives for this series are:

  • Create a fluent interface on the finders
    • Chain the find methods so that you can find on more than one method (method chaining).
    • Create an interface for sorting.
    • Create an interface for paginating the results.
  • Allow a service request (coarse grain) to be mapped to a specific fluent-interface call.
    • Based on information provided to a service as a request object, determine the right strategy for satisfying the request.
    • Execute the relevant strategy to perform the relevant queries
    • Return the query results to service method that was called.
    • The service method will return results as a response object.
  • Drive out these behaviours using TDD/BDD.

The outcome of this work will allow you write something like:

repository.find.ByThis(somevalue).AndFind.ByThat(someOtherValue).SortBy(aField, InAscendingOrder).Paginate.WithPageSize(10).ShowPage(1);

Before I start, one of the main benefits of a fluent interface is that you create an API that guides and limits the decisions that can be expressed in a logical order. So the interface needs to limit the options as the expression flows, which ultimately means you need to plan out the branching and the interfaces for each branch and decisions to ensure that public interface is meaningful to its context.

Table of Contents

Precursor

Part 1  (this post)

  • Refactoring the existing interfaces to provide interface segregation.
  • The Query Command
  • Method Routing
  • Method Chaining

Refactoring

Following on from the precursor, I need to stop my “IApplicationUserFinder” from implementing the “IEntityFinder” interface. The reason for this is the the  “IEntityFinder” interface exposes a property called DataSource. The published Fluent interface will want to expose the Find methods but not the DataSource property. So a bit of interface segregation is needed here to expose the right interface to the relevant consumer. While doing this refactoring, I decided that the name of the “IEntityFinder” is not right so I have renamed it to “IQueryableDataStore”. Although I have changed these interfaces around my concrete class  ApplicationUserFinder still need to implement both. So I have created yet another interface called “IQueryableApplicationUserFinder” which implements the “IQueryableDataStore” and “IApplicationUserFinder” interfaces. Now the ApplicationUserFinder class just implements IQueryableApplicationUserFinder. If I have scrambled your brain up, hopefully the code snipets below will make things clear.

    public interface IQueryableDataStore where Entity : EntityBase // was IEntityFinder
    {
        IQueryable DataSource { get; set; }
    }
...
    public interface IQueryableApplicationUserFinder :
        IApplicationUserFinder,
        IQueryableDataStore
    {
    }
...
 public class ApplicationUserFinder : IQueryableApplicationUserFinder
...

Now, how is this used. The ApplicationUserFinder is injected into the ApplicationUserRepository and then exposed via a getter (all by interfaces).  With the “IQueryableApplicationUserFinder” now in play, here is the revised code snippet for the repository (remember to change your IoC container to accommodate these changes).

    public class ApplicationUserRepository : EntityRepository,
        IApplicationUserRepository
    {
        private readonly IQueryableApplicationUserFinder finder;

        public ApplicationUserRepository(IPersistanceRepository repository,
            IQueryableApplicationUserFinder finder) : base(repository)
        {
            this.finder = finder;

            this.finder.DataSource = Query();
        }

        public IApplicationUserFinder Find
        {
            get { return finder; }
        }
    }

At this point, all my unit tests pass and application runs the same as it did before this refactoring.

The Query Command

Regardless of the expression that you can write using the fluent-interface, it needs  an end at some point. The Query Command objects is responsible for executing the query and return the result. I am using “Linq for objects” to write my queries and passing an IQueryable around under the covers, the execution of the queries is deferred until a method is called on it like “ToList()”. Calling the “ToList()” method will execute the underlying query.  I have  created a command object (based on the command pattern) to expose an “Execute” method that is going to return an IEnumerable<Entity>. The reason for returning “IEnumerable<Entity>” is that you have a vast about of extension methods that you use to execute the query. For example “ToList()” and “FirstOrDefault”. We can create the Query Command now and integrate it into the fluent-interface later with out much effort.

    public interface IQueryCommand where Entity : EntityBase
    {
        IEnumerable Execute();
    }

    public class QueryCommand : IQueryCommand
    {
        private readonly IQueryableDataStore queryableDataStore;

        public QueryCommand(IQueryableDataStore queryableDataStore)
        {
            this.queryableDataStore = queryableDataStore;
        }

        public IEnumerable Execute()
        {
            return queryableDataStore.DataSource.AsEnumerable();
        }
    }

So how can the fluent-interface get to this endpoint? Answer: we need an object to return it, so we can call it. I have defined this as “MethodRouter”.

Method Router

The method router exposes the actions that could be performed after a find method is called. As this is based on my previous post Implementing the Repository and Finder Pattern, I am going to change the original unit tests to drive out the method router. Here is the original specification for the “ApplicationUserFinder” class.

    [TestFixture]
    public class When_executing_queries_against_application_users
    {
        private ApplicationUserFinder finder; // subject under test

        [SetUp]
        public void Setup()
        {
            finder = new ApplicationUserFinder();

            finder.DataSource = GetStubbedCollection();
        }

        [Test]
        public void Should_return_a_user_by_login_name_when_supplied_a_known_login_name()
        {
            ApplicationUser result = finder.ByLoginName("Test.User3");

            Assert.That(result.LastName, Is.EqualTo("User3"));
        }

        [Test]
        public void Should_return_a_user_by_token()
        {
            ApplicationUser result = finder.ByToken(Guid.Empty);

            Assert.That(result.LastName, Is.EqualTo("User2"));
        }

        [Test]
        [ExpectedException(typeof(ArgumentNullException))]
        public void Should_fail_if_supplied_null_login_name()
        {
            IQueryable users = GetStubbedCollection();

            ApplicationUser result = finder.ByLoginName(null);
        }

        private IQueryable GetStubbedCollection()
        {
            List users = new List
            {
                new ApplicationUser { FirstName = "Test", LastName = "User1", LoginName="Test.User1", Token = Guid.NewGuid() },
                new ApplicationUser { FirstName = "Test", LastName = "User2", LoginName="Test.User2", Token = Guid.Empty},
                new ApplicationUser { FirstName = "Test", LastName = "User3", LoginName="Test.User3", Token = Guid.NewGuid()},
                new ApplicationUser { FirstName = "Test", LastName = "User4", LoginName="Test.User4", Token = Guid.NewGuid()},
                new ApplicationUser { FirstName = "Test", LastName = "User5", LoginName="Test.User5", Token = Guid.NewGuid()}
            };

            return users.AsQueryable();
        }
    }

As you can see from the above tests, each find method returns the result as a single domain entity. I now want to return an interface of the Method Router instead. The Method Router at point will expose the QueryCommand so that I still execute the queries and keep the code in a “close to working” state at all times.

To start with, I defined the MethodRouter interface “IApplicationUserFinderActions”

    public interface IApplicationUserFinderRouter
    {
        IQueryCommand Output { get; }
    }

Now, I need to change the return types in the IApplicationUserFinder to now return the IApplicationUserFinderRouter instead.

    public interface IApplicationUserFinder
    {
        IApplicationUserFinderRouter ByLoginName(string loginName);
        IApplicationUserFinderRouter ByToken(Guid token);
    }

At this point, things a little broken, so I need to change the concrete ApplicationUserFinder class to implement the changes made to the interface. To do this the concrete finder will need to know about the Method Router class. The method Router’s responsibility is to act as a hub to link object instances together. With this in mind, the MethodRouter class will need to know about the finder and the QueryCommand class. Still being mindful of the fluent interface and members it exposes, I need to ensure that the QueryCommand knows about the IQuerable instance held in the finder without coupling the objects together. To achieve this, I going to use the same technique I used in the Refactoring effort being the i return different interfaces to different parties. I have created another interface “IFindableApplicationUserFinderRouter” that implements IApplicationUserFinderRouter with an additional member.

Here is the new interface

    public interface IFindableApplicationUserFinderRouter
        : IApplicationUserFinderRouter
    {
        IQueryableApplicationUserFinder Finder { get; set; }
    }

Here is the concrete class ApplicationUserFinderRouter at this point.

    public class ApplicationUserFinderRouter : IFindableApplicationUserFinderRouter
    {
        private IQueryCommand queryCommand;

        public IQueryableApplicationUserFinder Finder { get; set;}

        public IQueryCommand Output
        {
            get
            {
                if (queryCommand == null)
                {
                    queryCommand = new QueryCommand(Finder);
                }

                return queryCommand;
            }
        }
    }

Here is the changed ApplicationUserFinder

    public class ApplicationUserFinder : IQueryableApplicationUserFinder
    {
        private readonly IFindableApplicationUserFinderRouter router;
        private IQueryable users;

	
        public ApplicationUserFinder(IFindableApplicationUserFinderRouter router)
        {
            this.router = router;
            this.actions.Finder = this;
        }
	

        public IQueryable DataSource
        {
            get { return users; }
            set { users = value; }
        }

        public IApplicationUserFinderRouter ByLoginName(string loginName)
        {
            if (string.IsNullOrEmpty(loginName))
            {
                throw new ArgumentNullException("loginName");
            }

	    
            users.Where(u => u.LoginName == loginName).FirstOrDefault();

            return router;
        }

        public IApplicationUserFinderRouter ByToken(Guid token)
        {
            users.Where(u => u.Token == token).FirstOrDefault();

		
            return router;
        }
    }

Here is a snippet of how one of the unit tests is looking.

	[SetUp]
        public void Setup()
        {
            router = MockRepository.GenerateStub();

            finder = new ApplicationUserFinder(router);

            finder.DataSource = GetStubbedCollection();
        }

        [Test]
        public void Should_return_a_user_by_login_name_when_supplied_a_known_login_name()
        {
            ApplicationUser result = finder.ByLoginName("Test.User3").Output.Execute().FirstOrDefault();

            Assert.That(result.LastName, Is.EqualTo("User3"));
        }

At this stage is hard to see the advantage of this apart from separating out code. The next step is to allow the find methods to be chained together (method chaining).

Method Chaining

The IApplicationUserFinderRouter interface is going to allow the finder to be returned from a property. This is pretty simple stuff. Below is the interface with the new property and the concrete class implementing this addition member.

    public interface IApplicationUserFinderRouter
    {
        IQueryCommand Output { get; }
        IApplicationUserFinder AndFind { get; }
    }

    public class ApplicationUserFinderRouter : IFindableApplicationUserFinderRouter
    {
        private IQueryCommand queryCommand;

        public IQueryableApplicationUserFinder Finder { get; set;}

        public IQueryCommand Output
        {
            get
            {
                if (queryCommand == null)
                {
                    queryCommand = new QueryCommand(Finder);
                }

                return queryCommand;
            }
        }
	
        public IApplicationUserFinder AndFind
        {
            get { return Finder; }
        }
    }

This now allows the find methods to be chained so you can write the following code

        [Test]
        public void Should_return_a_user_when_finding_by_Login_name_and_token()
        {
            ApplicationUser result = repository
                .Find.ByToken(Guid.Empty)
                .AndFind.ByLoginName("Test.User2")
                .Output.Execute().FirstOrDefault();

            Assert.That(result.LastName, Is.EqualTo("User2"));
        }

That concludes this post, the next part of this series will cover paginating the results returned from the underlying query.