Monorail vs. ASP.NET Webforms

In this document we will attempt to compare pros and cons of using Monorail versus using standard ASP.NET webforms. Hopefully this will make it easier for you to decide which one is more suitable for your project.

ASP.NET webforms

ASP.NET webforms were introduced by Microsoft with .NET framework.

Pros

ASP.NET takes a step away from ASP (where views, business logic and data access could, and often were, all mixed together). There are many features and benefits in using ASP.NET, and we will try to list the most important ones:

• Compiled code - Results in better performance.
• Powerful infrastructure - .NET framework is accessible and it can provide a lot of solutions for different kinds of problems.
• Controls - This is one of the cools new things in ASP.NET. Now just like in Windows programming one developer (or 3rd party company) can create controls and another developer can use them to write web applications. It also makes small web pages creation quick. All you have to do is drag several controls on the page. All the coding is done automatically by the designer.
• Designer with preview - When you're creating a website it's often important to see what you're making. The VS designer shows a preview of the pages and makes it easier to create the design you want.
• Large community - ASP.NET webforms has been out for quite some time now and it continues to gain popularity. There are a lot of professionals in the field so getting help is often easy.

Cons

While ASP.NET webforms can simplify life compared to ASP, things can still become very complicated very fast. A lot of features that look good at first in time turn into nightmares. ASP.NET webforms also miss some of the features present in Monorial, such as master pages (layout). Some of them will be added in .NET 2.0, but some (such as filters) will still be absent or hard to implement.

• Complex page lifecycle - You have to pay attention to "page_load ? method and ensure everything is wired correctly.
• VS designer - It's simple to use. All you have to do is drag controls on the page, go to the properties and create event handlers for the control. It has big disadvantages though. First it can easily mess up your carefully crafted HTML (this should be fixed in VS 2005). What's more important it makes initial code writing simple, but it's hard to read or maintain it later. It makes it very easy to mix view controller code with logic code if you're not careful. It takes away the development phase where you think about design and ensure code is separated correctly.
• Controls - They can make a lot of code easy to reuse, but a lot of people go too far and shove it in every hole they can find (or designer does it for them), instead of doing simple things simpler. In the end large amount of controls can easily hurt design and code readability, not to mention performance.
• Complex view state management - Idea of view state retention is a great one. It should, at least in theory, simplify view management and configuration. In practice things become too complicated for both simple and complex case (often due to the fact that you don't directly see or think about the view state until it grows too large and hinders performance and web page size).

Monorail

Monorail is an intelligent port of Ruby on Rails to .NET framework. It attempts to simplify web development and address some of ASP.NET webforms issues. It's built on top of ASP.NET infrastructure so a lot of ASP.NET features (i.e. session control) are still available to the Monorail. There are both advantages and disadvantages to using Monorail. We always attempt to minimize the latter, but it will be hard (if not impossible) to eliminate all of the cons.

Pros

• Simple - Monorail aims to be simple and intuitive to use. Configuration is minimal and many things get auto-wired automatically. A lot of thought is given to every new feature to ensure it doesn't break common design goals.
• Separation of concerns - Your code is encouraged to be separated into several layers: views, controllers, etc. Separation between views and controllers is enforced, but separating code further is just a next logical step. There's no automatic designer to hide from you view-controller wiring so you're forced to think more about logical structure of your code.
• Designed to work with other Castle parts - Castle is a large project with different sub-projects to simplify different programming tasks (data-base access, components management, etc.) They are all designed to be simple and to work well together. Monorail on itself is great, but when used with other Castle projects it becomes truly wonderful.
• Several view engines - Currently there are three view engines, each offering distinct advantages and disadvantages. More view engines are in the works and framework can be extended to support any custom engine you might want to use.
• Filters/Rescues/Layouts - All are advanced features offered by Monorail. Probably all of them can be done in ASP.NET webforms, but it will be a painful process, while in Monorail they're simple to add.
  • Filters - Provides a way to do pre and post processing of the action. For example it can be used to direct a user to log-in screen from some web page that requires authentication.
  • Rescues - Associates an error page to show per controller or per action.
  • Layouts - Associates master page with a view. Simplifies design reuse and promotes common look for the website.
• Open source - Even though ASP.NET webforms is free (since .NET framework is free). It's closed source. All Monorail source is freely available, which can often make it easier to figure out why something isn't working as expected.
• Single, active community - The community is very active. When you have any questions, concerns, problems there is a single place to go to get help and you will get it quick.

Cons

• Small community - While Monorail community is very enthusiastic and active it is still pretty small, tiny in comparison to ASP.NET webforms community. Monorail is not being used very widely so there's still a minimal chance of hidden bugs and there aren't many examples available on the Internet.
• View engine issues - Even though there are several view engines none of them are perfect.
  • nVelocity - Good template language, but the project pretty much dead. Monorail developers took over it to fix some of the biggest issues, but not a lot of work is being done on it. At the same time it's one of the more intuitive engines to use with Monorail.
  • Webforms - Monorail supports familiar ASP.NET webforms (.aspx) pages. Unfortunately it's design makes it easy to start mixing code from different layers. Webforms have also limited support of some more advanced Monorail features (ViewComponents aren't supported for example).
  • Brails - View engine based on Boo. The language uses Python syntax and not all developers like it. It does provide a good alternative to nVelocity though.
• No designer - There's no designer for the views (other than webforms views) and so it's impossible to see how the view will look until the website is opened in the browser. However this is a minor problem since writing code for Monorail is much simpler than for ASP.NET.
• Not release version - Monorial is very stable, but it's not in release yet. There are still some things that we plan to implement before Monorail can be released:
  • Better view engines
  • Better scaffolding support
  • Caching
• Lacking documentation - While there are several articles describing how to work with Monorail we realize documentation is not nearly complete. It might still be hard to figure out how to do something and to realize the full potential of the framework. There are however forums and mailing lists you can use to get direct help from other users and developers.

Retrieved from "http://wiki.castleproject.org/index.php/MonoRail:MonoRail_vs._Webforms"