Building my first Monorail application

If you've read my blog you'll know I'm a big fan of the Castle project. I even spoke at DDD6 in November about the Castle Project's IoC container, Winsdor. The castle project is probably best know for it's rails-a-like MVC framework for ASP.NET, Monorail. Indeed recently Microsoft have focused an awful lot of attention on Monorail by announcing their own MVC framework. Apparently they even invited Hammett, the leader of the Castle Project up to Redmond to pick his brains.

I've been itching to have a go at building an application based on Monorail for months now and with no work to distract me since the end of November I've been able to indulge myself. I've taken an example that I've worked on commercially, a job board, and started building a complete application from scratch with the Castle project stack. I'm using Monorail as the application framework, ActiveRecord for data access and Windsor as the IoC container. The project's called Jobvertizer and you can download the code from the Google code project here. I need to put together some instructions for deploying it, but I probably won't do that until I get around to putting it on a public server, hopefully not to far in the distant future.

I've really enjoyed playing with Monorail. The philosophy behind it resonates with my own beliefs about how code should be written. There is a full suite of unit tests and everything is abstracted, which allows you to insert your own behavior into the framework at will. Because it's written for TDD there are mock versions of many of the core classes ready to be used and even abstract test base classes for testing controllers and view components. That's really nice. Probably the main thing that's struck me though, is how easy web development is when your framework's model is sympathetic to the HTTP protocol. What do I mean by that? Well, I've been doing Web Forms for many years now, and even with much experience, I still find it hard to grep sometimes. The whole event driven model simply doesn't mesh with the stateless request/response pattern of HTTP. When your framework explicitly divides handling the request from rendering the response, everything suddenly becomes much clearer.

The amount of code I've had to write for this application is only a fraction of what a similar Web Forms project would have required. It almost seems that at every step there's a convenient shortcut. I especially like the data binding and form helpers; they make it a sinch to rapidly develop CRUD interfaces. Using Active Record and NHibernate means that I've rarely even opened SQL Management Studio. I haven't had to write a single line TSQL or create a single table. Being able to take all the data access stuff for granted is a major productivity win. I've also used scaffolding for much of the admin interface, and while this wouldn't be suitable for an end user facing application, as a quick win to provide admin access to lookup tables, it's fantastic.

What is there not to like? Well I've gone along with ActiveRecord (with a few changes, like separating the model from the repository) and it's "data objects" which are simply collections of properties with a one-to-one mapping to the database tables. Indeed, I've used the shortcut of generating my schema from my model. But I've noticed that not being able to write a fully encapsulated domain model with enforced business behavior does introduce more bugs than I would have liked. Not being sure that a model object I was playing with was properly formed has tripped me up several times.

I'm also not sure about the profusion of string literals and dictionary based property bags. I'm very much a strongly typed kind of guy and it scares me when I know the application is relying my ability to spell and remember what I've called things. This same unease extends to the NVelocity view engine. It's fine, it works, I haven't found any real gotcha's and I've been able to do pretty much everything I wanted, but I'm so used to intellisense and a compiler checking everything for me that I can't help feeling nervous.

Finally there's the documentation. If you're a dyed-in-the-wool MS developer like me, you're probably not that used to working entirely in an open source framework. It's a very different experience from working with an MS toolkit. Firstly it evolves rapidly. I find I'm constantly reading stuff about Monorail that's out of date. Stuff gets added and changed from month to month and I've found the best way of finding out what's really going on is to look at the latest source. Of course that's fine if know generally what you're looking for, but when you need advice about basic approaches, it's awkward if the documentation you're reading shows a much older way of doing things. Secondly, the documentation that is there tends to be pretty basic; maybe a general outline of how to go about things, but very little in depth. But, I must say that having the code to look at, especially the unit tests makes a fantastic difference. Of course I've been using reflector for years, but it's not quite the same. Microsoft's recent announcement that it's publishing the source code for the .NET framework libraries is an effort to compete with this obvious benefit of open source software.

I'll be continuing to develop this application and learn more about Monorail as time allows. I'd like to tart it up a bit and get it publicly deployed next. Stay tuned!