Calle Arnesten's Blog

Igår la jag upp www.dumbbell.se för allmänheten. Dumbbell.se är en träningscommunity där man kan mata in sina träningspass, se statistik hur man utvecklas och diskutera med andra träningsintresserade människor. Siten kommer byggas ut gradvis närmsta tiden.

Rent tekniskt så har jag använt mig av ASP.NET MVC, NHibernate och jQuery i en härlig symbios :)

Jag kommer troligtvis skriva fler inlägg om dumbbell.se här i framtiden, men detta får vara tillräckligt för stunden.

On the web it’s considered a good practice that the GET method never changes the state on the server. When state should be changed the POST method should be used. It is good to follow this practice, otherwise there might be problems when search engines tries to visit links (which are GET by default).
By default in ASP.NET MVC any public method on the controller can be accessed both by GET and POST. So I _could_ access my DeleteUser() method by an ordinary link (which is GET).

So, how do I restrict a method in ASP.NET MVC to be only GET or only POST? I could use ActionFilterAttribute and tag each method with it. But tagging every method is a bit noisy in my opinion. The thing I want is GET to be the default way to access methods, and then I want to mark POST methods only with attributes.

In my MVC projects I always have a BaseController, that all my controllers inherit from. With that in place it is actually quite easy to accomplish the above. I just need to override OnActionExecuting like this:

public class BaseController : Controller
{
    protected override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var attributes = filterContext.ActionMethod.GetCustomAttributes(
            typeof(POSTAttribute), false);
        var method = filterContext.HttpContext.Request.HttpMethod;
        if (attributes.Length > 0 && method != "POST")
        {
            ThrowIllegalMethodException("POST", filterContext);
        }
        else if (attributes.Length == 0 && method != "GET")
        {
            ThrowIllegalMethodException("GET", filterContext);
        }
    }

    private static void ThrowIllegalMethodException(string expectedHttpMethod,
        ActionExecutingContext filterContext)
    {
        var controllerName = filterContext.Controller.GetType().Name;
        var controllerMethod = filterContext.ActionMethod.Name;
        var httpMethod = filterContext.HttpContext.Request.HttpMethod;

        var message = string.Format("Only {0} method allowed for {1}.{2}, but {3} was used.",
            expectedHttpMethod, controllerName, controllerMethod, httpMethod);
        throw new SecurityException(message);
    }
}

And also I need a POSTAttribute which is simplest possible:

public class POSTAttribute : Attribute
{
}

So, now I can write [POST] above methods like this:

public class MyController : BaseController
{
    [POST]
    public ActionResult SaveMyEntity()
    {
        // Code..
    }
}

Pretty cool that you can change the behaviour of the MVC framework this easy.

Just read this. This is great news! I don’t like the way WebForms work today, I think its hard to get testable code close to the UI. I know there are alternatives like MonoRail, but I find the disadvantage of not having third party components like Telerik too big. But if a framework for Model View Controller comes from Microsoft, I’m sure that third party component companies will start develop components for it.

I arrived yesterday to Aarhus in Denmark for the ongoing JAOO conference. I’m here for two tutorials, one about Test-driven development (TDD) which I went to today, and one about domain-driven development (DDD) which I will visit tomorrow.

The TDD tutuorial was held by Robert C. Martin, also called Uncle Bob, whom have written a couple of books (none of which I have read yet, unfortunately). I found Robert to be charismatic, loud-mouthed (not in a negative way) and generally a funny guy.

The tutorial begun with a short introduction of TDD and then went on with a presentation of the requirements to a game called “Hunt the Wumpus” (wtf is a Wumpus?!). The requirements were written in a tool called FitNesse. FitNesse is a popular tool for writing what is called acceptance tests. These acceptance tests should non-programmers, typically QA or management people, be able to write.

After the introduction we were given an incomplete implementation of the game, along with a lot of acceptance tests which didn’t pass. Our objective was to use TDD and write code to make the acceptance tests pass. Every change we made to the game code had to be as an effect of creating a unit test that failed.

I’ve personally been writing unit tests for two years now, but haven’t done any real TDD until very recently. So I’m still in the process of re-learning the way to write code. In TDD you should “Write the test that force you write the code you want” as Robert so elegantly put it. More formally there are three rules of TDD which are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

If you practice TDD properly you should, accordingly to Robert, produce more than 1000 unit tests per year. That is a lot more than what I’ve produced my last year! And then I actually thought that I had been writing a lot of tests.. But when you think about it, it’s not really an unreasonable amount. Knock it out over a year and it’s just about 4 tests per day. Now it didn’t sound so much, did it?

Throughout the day, Robert interrupted regularly to ask the audience questions and share his opinions about difference aspects of software development. I will present some of the nuggets here:

“Comments are dirt in code”. My favourite! What he means is that most of the time comments in code try to make up for poor design. If the design was really good, the comments wouldn’t be needed. I really agree with this reasoning when it regards that comments shouldn’t be needed inside code blocks. However, public comments that clarifies, for example what state a parameter must have (not null is common), I still think are needed sometimes, especially for APIs where you don’t have access to the source code.

“Implement new functionality in priority order, not what is convenient from a design point-of-view”. This sentence stuck since we’ve been discussing this lately at the company I work for. The reasoning behind it (besides the obvious point that high priorities are more important than low priorites) is that the design should be refactored continually so that the best possibly design will emerge independently of the order that the tasks are implemented.

He also gave so guidelines of method design. A well-designed method should:

• not be longer than 5 lines of code
• not have indentation depth (like for and if statements) of more than 2
• not have more than 2-3 parameters

Personally, I’m not quite there yet when it comes to the first two statements. I try to make my methods short, but sometimes they are up to 30 lines of code.. And my indentation depth often goes up to three or sometimes even four.

At the end of the tutorial, there was time for reflections of working with TDD and a question from the audience was that they had gotten redundancies where some unit tests were almost identical as some of the acceptance tests. This was okay, according to Robert.

On the negative side I don’t have much to say.. Perhaps only that he at one time used exception handling for taking care of bad user input from the command line. In my book*, exception handling should only be used for exceptional events, not such a common case as when a user misspells a command..

All in all, I found the tutorial very giving and inspirational. How much the tutorial will affect my development process, I don’t know yet.. But I think I’ve gotten enough knowledge and energy to really start doing real test-driven development from now on. It will be fun to reflect upon this in a couple of weeks.

* No, I haven’t written any books. I mean the figure of speech.

One of the things I missed when I started to look at Cuyahoga two weeks ago was that it didn’t use NHibernate 1.2. As I was used to NHibernate 1.2 from my work with its support for generics, I wanted to use that with Cuyahoga as well. So I decided to make a patch that would enable me to use it.

Besides using the files from the NHibernate 1.2 release, I had to download the subversion source code for Castle.Facilities.NHibernateIntegration.dll. Then I had to make a few adjustments to the code for it to compile against NHibernate 1.2.

After I had upgraded the dll’s, the Cuyahoga compiled. But when I run it NHibernate complained on some things like missing virtuals and wrong mapping scheme (urn:nhibernate-mapping-2.0 instead of urn:nhibernate-mapping-2.2). After that it seems to be working nice.

You can download the patch for Cuyahoga 1.5 source code here. And for Cuyahoga’s latest trunk here.

Unfortunately, I’ve been having some problem applying the entire patches. It complains about some strange character in the beginning of some of the repository files, so you might have to manually edit some files. (The patch file is actually quite human-readable so it can be of help in the manual process). But for those that start from scratch I’ve also created a ready package of Cuyahoga 1.5 with patch applied. Download it here.