Part I – Why Use Monorail?

Monorail is a MVC implementation that sits on top of ASP.NET . It is an alternative to Webforms.

“Monorail is a simplification of the standard Webforms paradigm” sums it up quite well. There is no complex ‘page lifecycle’ in Monorail. No ‘postback’ or ‘viewstate’. Instead, it’s a return to the Http protocol of POST/GET and Response/Request

From the W3 on the Http

“It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.”

Webforms attempts to abstract this away from the developer by giving the illusion of state in a stateless protocol. Whereas Monorail builds on this, there is no attempt to abstract this away. The end result is that it’s easier to work with. With Monorail separating out the controller (the ‘real code’) from the view, which is a template engine with FormHelpers to make developing a rich UI quite easily. (Note: there are several views, but I’m just concentrating on NVelocity, a template engine that was ported from Java and originally written in C)

  • Monorail is extensible and can be used with existing API’s, such as javascript libraries, quite easily. For example, with Monorail I was able to grab the Tab component from the Yahoo UI and have it running on my Monorail page in 10 minutes. With Webforms, you have to fight the page lifecycle, etc… One of the negatives I hear (and I thought myself), was that I’d be out of luck with Monorail because I wouldn’t have my nice friendly controls. What I’ve learned is that I’ve been limited to the complex controls created by others or spent hours coding up my own controls whereas there tons of prebuilt UI components for the web out there outside of Webforms! The key here is how easy it is to integrate these into your solution. Additionally, Castle creates other API’s that co-exist quite easily with Monorail, including Castle Windsor Container (IoC) and Active Record (ORM – sits on top of NHibernate).
  • Monorail helps to enforce the concepts of the ‘Single Responsibility Principle’ and Separation of Concerns by utilizing the Model View Controller architecture. In turn, this allows for a loosely coupled and cohesive design.
  • Monorail supports test-driven development. Controller and the interfaces used in Monorail make it easy to test your code. It includes test harnesses to make it easy to create the controller. A base class is provided, “BaseControllerTest”:

public void SimpleControllerAction()
     SimpleController simpleController = new SimpleController();
     PrepareController(simpleController, "areaName", "simplecontroller", "index");


     // Some Assertions here

The Castle website includes more examples on NUnit testing: Learn more on testing.

Controllers just handle application flow, models represent the data, and the view is just concerned about presentation logic. Consequently, you write less code and end up with a more maintainable application.

Part II – How Monorail Works

3 thoughts on “Part I – Why Use Monorail?

  1. Hi, thanks for providing the article on Monorail. Unfortunately in my experience the reality is almost entirely contradictory to your article. Working with monorail results in a nightmare of complexity and half baked solutions.

    Maybe that’s because there is so much to take into account, it certainly is far more troublesome than forms based development and I seem to spend much of my time these days re-writing monorail/castle mvc projects that simply don’t work.

    I’m not a monorail/castle developer and with each failed project, built with this set of technology, I encounter I just become more dissolusioned with it.

    I think what started out as a good idea has turned into a bigger mess than the “problems” it was originally designed to resolve.

    Perhaps that’s down to developers, adopting technologies without really understanding them, what can be done or how it should be done!!

  2. Steve, thanks for your feedback.

    I will just say, this was written in 2008. At that time there was no mvc, and Monorail was a big reason mvc even came to exist.

    I have not used Monorail lately, as I’ve been using MVC. But when this article was written, Monorail was running very well and was quite a nice alternative to webforms.

    That said, I can’t really comment on it’s state today.

    Thanks again

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s