Cranking out Code

Following the Evaluating a move from Monorail over to ASP.NET MVC post, I started to dig deeper into the authorization mechanism in ASP.NET MVC. There were some core differences, in ASP.NET MVC they had taken a step further with authorization and created a specific filter Authorize implementing the IAuthorizationFilter interface. This enables you to specify users and roles that are authorized to invoke a certain action on a controller. For example if you require that only users in the "Administrators" role are allowed to invoke Index() it would like this:

Where you decorate the controller with a special [Authorize(Roles="Administrators")] filter attribute. This [Authorize] filter would check the user before invoking the Index() method. If the user did not had the specific role it would output an error. If the user is not logged in it would be redirected to the login page etc.

This is very nice, you can do the same in Monorail since filters exists in both ASP.NET MVC and Monorail. However, in Monorail you had to specify that the filter would be executed before the action is invoked and there is no special treatment for the filter. It's treated just like any other filter. In my application it looks like this (the selected line):

You explicitly has to specify that the filter should be executed before the action, it wouldn't make much sense otherwise for an authorization filter, if it would be invoked after the action has been executed. To make sure that you don't miss this they specifically created an interface IAuthorizationFilter which always will be executed before any action. Personally I really like this approach, this way you won't accidentally forget to specify it should be executed before any action.

So far so good, in ASP.NET MVC there's no need to explicitly specify it should be executed before and there's no question about what the filter does, just read the name of the filter. Unfortunately, since the Authorize filter in ASP.NET MVC only works with users and roles I either has to change my Monorail authorization and permission scheme or implement a new feature in ASP.NET MVC. In my application I do not specify Users or Roles in the application, instead I use permissions after a suggestion from Christer. I must say it's been great, the system feels a lot more flexible when I can define different permissions. For example my job advertisement controller has five actions: Create, Update, Delete, Read and Approve. Which gets translated into five different permissions CreateAdvertisement, UpdateAdvertisement, DeleteAdvertisement, ReadAdvertisement and ApproveAdvertisement. The actions on the controller are decorated with the suitable permission. This way I can manage the permissions so that any user can read advertisements. Any logged in user can create and update their own job advertisement. Only administrators can approve new job advertisements and delete existing advertisements. In the administration view it's possible to change these permissions.

Of course, this can be done using roles only. Hard coding in roles into the application. But this way, there's another layer of abstraction which hopefully doesn't need to change after all permissions are specified. Another advantage using this permission approach is that whenever you need to add another role to the system you only need to specify it and then go into the administrations view and determine which rights the role should have. No need to browse through each action for each controller in the system, and hoping that you didn't miss any.

Fortunately, the team behind ASP.NET MVC has made it super easy to just create a new authorization filter. All you need to do is create a class that implements the IAuthorizationFilter and inherits from the FilterAttribute class (actually, I'm not sure it needs to be derived from the FilterAttribute class). For example I created the RequirePermission attribute, which implements the IAuthorizationFilter. The only method in IAuthorizationFilter is the void OnAuthorization(AuthorizationContext filterContext). After that I could decorate my Delete() method with the new AuthorizationFilter: RequirePermission.

Which would enable the system to verify the role of the user against the relation between role and permission.

I must say that ASP.NET MVC has made some progress regarding authorization, comparing to Monorail. They are almost implemented identically, however there are some subtle differences that makes a huge difference in my opinion. It's impressive how easy it is to implement new filters in ASP.NET MVC.

I started building a web site for my father a few years ago, back then I based it on PHP/MySQL. After some time I discovered Ruby on Rails and rebuilt most of the system using RoR, although I didn't complete the project for a few reasons (not going into detail here). Late 2007 I started to thinking about rebuilding it and leaned toward using .NET. I was thinking I could use it to try out some new technologies in .NET that I hadn't used yet. I'm not a big fan of ASP.NET, so using traditional ASP.NET was out of the question. Since I'm used to PHP and using POST/GET and reading query strings etc I feel that ASP.NET actually confuses developers with postbacks, events and viewstates causing all sorts of problems. Another issue of ASP.NET is the testability, it's cumbersome to write unit tests for ASP.NET applications, it's possible for example using a Model-View-Presenter (MVP) pattern.

Looking for another web framework to use I found Monorail, which is a MVC framework by Castle Project inspired by ActionPack. It's built on top of ASP.NET but, everything gets routed to an action on a controller. I also discovered ASP.NET MVC, however, it was so early that it felt like it changed a lot between every preview, big breaking changes which would meant fixing a lot of code whenever upgrading to a newer preview. That's way I settled with Monorail for the time being.

The web application that was built had the following features

• Membership (Users, groups and permissions)
• CMS (pages and menus)
• Questionnaire
• Create conference and have members registering to attend
• Create, send as PDF and manage invoices (the sum of the invoices for the last conference was close to $350 000)
• Post job advertisements
• Forum

The web framework used was Monorail and for data access I used NHibernate with ActiveRecord, which made my life so much easier. It's incredible powerful to be able to re-create the database with just a command and be able to switch between different databases by only changing the configuration. At one time I developed the application on my development machine which had a SQL 2005 server and I deployed to a MySQL server and it worked right out of the box. I used the ability to destroy and create the database a lot when creating integration tests. No need to try to reset the database to a specific state, now I was confident that everything was exactly the same each time I ran the tests. The database got swiped and created between each test. There's also the possibility to use an in memory database such as SQLite for performing integration tests, since it only resides in memory it's incredible fast.

I'm pretty pleased with the outcome of the system, it's working great and it's easy to add new features. But, I'm like many of you, I always want to try new things and learn more. Now when ASP.NET MVC has had almost a full year of development since I last visited it I feel like it's time for doing another re-build of the system. This time I'm hoping to be able to re-use some of the business logic and a lot of the data access layer since I'm still going to use NHibernate. I know Entity Framework (EF) has been released, but it's lacking a lot of features and is at the moment inferior to NHibernate. I'm sure it will turn out great when version 2 is released of EF, and I'll probably replace the data access layer when it's out :)

Looking through the code for the web application today trying to look for what needs to be replaced when moving over to ASP.NET MVC from Monorail, it feels like it's not really that much that needs to be changed. I could use a NVelocity view engine keeping the views more or less intact. The data layer is the same and since I wrapped everything in services the controller does not really contain a lot of logic, it'll certainly help. However, obviously there are some core differences between Monorail and ASP.NET MVC. I'm going to go over the issues I encounter one by one as I browse through the code looking for certain perks that needs to either be rewritten in ASP.NET MVC or could just be moved over simply by renaming some classes etc. I'm really looking forward to try out the new features in ASP.NET MVC that I haven't looked at yet, particularly that controller action is not void anymore, instead they return an object. This will make unit testing so much easier.