muonlab » 2010 » February

random .NET and web development musings

In order to use the UrlHelper class in your tests, you need to construct it with a ControllerContext, which consists of an HttpRequest and an HttpResponse. Unfortunately these are quite difficult to construct, as you’ll know if you’ve ever tried. Luckily, the UrlHelper doesn’t use much of these two classes, only a few properties, making them fairly easy to mock.

The first thing you need to do is get your routes, usually declared in your Global.asax MvcApplication

var routes = new RouteCollection();
MvcApplication.RegisterRoutes(routes);

Then you need to mock an HttpRequest

var request = MockRepository.GenerateStub<HttpRequestBase>();
request.Stub(x => x.ApplicationPath).Return("/");
request.Stub(x => x.Url).Return(new Uri("http://localhost/a", UriKind.Absolute));
request.Stub(x => x.ServerVariables).Return(new System.Collections.Specialized.NameValueCollection());

Then you need to mock the HttpResponse

var response = MockRepository.GenerateStub<HttpResponseBase>();
response.Stub(x => x.ApplyAppPathModifier(Arg<string>.Is.Anything))
    .Return(null)
    .WhenCalled(x => x.ReturnValue = x.Arguments[0]);

Then you can simply stick these two mocks onto a mock context, and use that to create your UrlHelper instance and set them on the controller you are testing:

var context = MockRepository.GenerateStub<HttpContextBase>();
context.Stub(x => x.Request).Return(request);
context.Stub(x => x.Response).Return(response);

var subjectUnderTest = new MyController(); // this is the controller you are testing

subjectUnderTest.ControllerContext = new ControllerContext(context, new RouteData(), subjectUnderTest);
subjectUnderTest.Url = new UrlHelper(new RequestContext(context, new RouteData()), routes);

Job done.

Now go and use OpenRasta and not have any of these problems.

In this post I’m going to discuss one method of implementing validation into your OpenRasta handlers using an OperationInterceptor.

OpenRasta deliberately doesn’t ship with a validation framework, there are plenty out there for you to use. For the purposes of this post, I’m not using any particular validation framework, simply demonstrating the point with a generic IValidator, something like:

public interface IValidator<TResource>
{
    ValidationReport Validate(object resource);
}

First, lets see a way you could do validation in an MVC sort of way:

public class EditUserHandler
{
    private readonly IValidator<EditUserResource> validator;

    public EditUserHandler(IValidator<EditUserResource> validator)
    {
        this.validator = validator;
    }

    public OperationResult Post(EditUserResource resource)
    {
        var validationReport = validator.Validate(resource);

        if (!validationReport.IsValid)
            return new OperationResult.BadRequest {ResponseResource = resource};

        // save user details here

        return new OperationResult.SeeOther {RedirectLocation = "~/ "};
    }

This is probably a very familiar pattern and something you could expect to see inside all hander operations which require validation. Meh. This duplication is not only wasteful, but its unnecessary noise cluttering up your Operation and we can get rid of it.

OperationInterceptors wrap the execution of an operation, giving you three places to interact, BeforeExecute, RewriteOperation and AfterExecute. In this instance, we are only concerned with BeforeExecution.

This method is called just before the Operation in invoked, this is where we want to examine the input parameters, and check if they are valid.

For the purposes of brevity, the below code assumes there is only one parameter to your operation method; hence the FirstOrDefault();

public class ValidationOperationInterceptor : OperationInterceptor
{
	private readonly IDependencyResolver resolver;
	private readonly ICommunicationContext context;

	public ValidationOperationInterceptor(IDependencyResolver resolver, ICommunicationContext context)
	{
		this.resolver = resolver;
		this.context = context;
	}

	public override bool BeforeExecute(OpenRasta.OperationModel.IOperation operation)
	{
		var input = operation.Inputs.FirstOrDefault();

		if(input == null)
			return true;

		var parameter = input.Binder.BuildObject();

		var validatorType = typeof(IValidator<>).MakeGenericType(parameter.Instance.GetType());

		if (!resolver.HasDependency(validatorType))
			return true;

		var validator = this.resolver.Resolve(validatorType) as IValidator;

		var validationReport = validator.Validate(parameter.Instance);

		if (validationReport.IsValid)
			return true;
		
		// add validation errors here

		context.OperationResult = new OperationResult.BadRequest { ResponseResource = parameter.Instance };
		return false;
	}
}

We register this OperationInterceptor as follows:

ResourceSpace.Uses.CustomDependency<IOperationInterceptor, ValidationOperationInterceptor>(DependencyLifetime.Transient);

The above code assumes that the parameter binding succeeded, I’ll demonstrate a way to deal with binding failures in a future post (its very similar to the above code).

So what effect does this code have? Well, it can make your handlers super clean:

public class EditUserHandler
{
    public OperationResult Post(EditUserResource resource)
    {
        // save user details here

        return new OperationResult.SeeOther {RedirectLocation = "~/ "};
    }

Your Operations are now only called when the resource is valid, excellent!

You may be seeing one obvious drawback with this approach, that being what if your resources need extra data setting on them before they get sent to the codec in the case of invalidity? When editing a user, perhaps the resource needs to also contain a list of possible authorization roles, one of which will be selected for the user. Having a single mechanism for handling validation for all types doesn’t allow you anywhere to set this extra information on the resource. Well, there is a solution I’ll be proposing in my next post.

So stay tuned :)

This is the 2nd part to my OpenRasta introduction (see part 1 here) in which I’m going to cover Handlers and OperationResults.

Handlers are very much like MVC Controllers, except that there is no base class or interface to implement 😀 This makes them incredibly lightweight and a dream to work with.

The OpenRasta equivalent of MVC Actions are Operations. These look very similar to their MVC counterparts except we return an OperationResult instead of an ActionResult.

OperationResults represent HTTP Status codes, and you should strongly consider the choice of OperationResult that you use.

public class FooHandler
{
    private readonly IFooService fooService;

    public FooHandler(IFooService fooService)
    {
        this.fooSerivce = fooService;
    }

    public OperationResult Get(int id)
    {
        var foo = fooService.Get(id);

        if(foo == null)
            return new OperationResult.NotFound();

        return new OperationResult.OK(foo);
    }
}

(similarly to my last post, I’ll ignore the fact that we shouldn’t be sending domain objects out of our handlers for brevity of the example)

In the above case, if the IFooService cannot find the request Foo object, we return an OperationResult.NotFound which is a direct representation of HTTP Status 404.

If it is found, we return an OK (HTTP 200) passing the Foo “resource” out as the ResourceResponse for encoding later in the pipeline.

OpenRasta code is designed with discoverability in mind, intellisense is your friend. Start typing:

new OperationResult.

and see the complete list of HTTP Statuses you can return. Different results have different arguments, for example:

new OperationResult.SeeOther {RedirectLocation = "~/somewhere" }

In OpenRasta, Operations have the name of the HTTP Verb you want them to respond to (you can override this behaviour with named operations, more on this later).

This means that you have a Handler per Resource, which is an excellent means of helping enforce S.R.P.

The last part we need is the registration.

ResourceSpace.Has.ResourcesOfType<Foo>()
    .AtUri("/foo/{id}")
    .HandledBy<FooHandler>()
    .RenderedByAspx("~/Views/Foo.aspx");

The brilliant fluent configuration API makes the above code very self explanitory, but just to clarify:

ResourceSpace.Has.ResourcesOfType<Foo>() // Tell OpenRasta about our Foo type
    .AtUri("/foo/{id}") // Providing the URI where Foos reside. The brackets are parameter templating just like MVC
    .HandledBy<FooHandler>() // Here we tell OpenRasta which class handles requests for Foos
    .RenderedByAspx("~/Views/Foo.aspx"); // Here we set a WebForms codec, using the given view

How much simpler could this be?

Next post we’ll look at Pipeline Contributors

Huddle are hosting an OpenRasta Code Camp on the 18th February at their London offices. You want to go to this.

You can read more about the event here and register for the event here.

You haven’t heard of OpenRasta? For those living under a rock, to quote from the wiki:

OpenRasta is a resource-oriented framework for .NET enabling easy ReST-ful development of web sites and services. OpenRasta is designed to run on .net 2.0 and above, and can co-exist peacefully with your existing ASP.NET and WCF deployments.

However, this statement alone does not come close to describing the awesomeness of OpenRasta.

OpenRasta is “resource-oriented”, this really cannot be understated. OpenRasta elegantly embraces the way HTTP is designed which immediately removes countless issues you encounter when using the likes of ASP.NET MVC.

For those who need an HTTP referesher, consider URIs. The clue is in the name, Uniform RESOURCE Identifier. A resource can be anything, to take Seb’s example from his Progressive.NET talk, a teacup.

Now you can’t send a teacup over the wire, but we can send an encoded projection. In MVC, you might do something like:

public ActionResult Get()
{
    var cup = teacupService.Get();
    return View("TeaCup", cup);
}

which will use the WebForms view engine to combine the TeaCup.aspx template with the cup resource (I’m going to overlook the fact that you shouldn’t be sending your domain objects out directly for brevity).

This is ok, but what happens when you want the teacup in JSON format? You can do one of two things. Either you create a whole new Action method:

public ActionResult GetAsJson()
{
    var cup = teacupService.Get();
    return Json(cup);
}

which immediately creates all sort of code smells; duplication, encoding concerns in the method names (and therefore url) and the method itself. Meh.

Or you could remove some of this duplication by having a single action method and checking the accept headers yourself inside the action method, but come on, seriously. Why should you have to do all this boilerplate/plumbing code yourself? I might as well just be using an HTTP Handler. What power is the Controller giving you if you’re having to do everything yourself?

Do not fear. OpenRasta is here! Lets see how we do the same thing in OpenRasta:

public class TeaCupHandler
{
    public OperationResult Get()
    {
        var cup = teacupService.Get();
        return new OperationResult.OK(cup);
    }
}

(obviously I’m ignoring error handling here)

But wait, I hear you cry! Where do I specify the encoding? In the configuration of course, somewhere completely separate to the above handler method, as it isn’t its concern.

ResourceSpace.Has.ResourcesOfType<TeaCup>()
    .AtUri("/teacup")
    .HandledBy<TeaCupHandler>()
    .AsJsonDataContract()
    .And.AsXmlDataContract()
    .And.RenderedByAspx("~/Views/TeaCup.aspx");

Look at that! One line of code for each type of encoding we want! *joys* The lovely fluent `.And.` allows you to chain up as many different types of encoding support as you like. And because OpenRasta is completely pluggable and extendible (no, it REALLY is, not like in the way MVC claims) you can write your own codecs with extreme ease.

So, that was a very brief introduction to encoding in OpenRasta. In future posts I will cover HTTP verbs and handlers in greater detail, and show you the power of the pipeline!