The usual FUD about MonoRail

July 26th, 2007

I’m aware that FUD may have a negative connotation, but this post will be about valid concerns that users have, especially people with a WebForms background.

But before going into that, there’s this discussion happening at Ayende’s blog. I just want to highlight a piece of comment by jdn (which has a PhD so he can’t be wrong!):

And, I’m not missing the point, I DO NOT WANT TO HAVE TO HAND-WRITE HTML everytime I want to have a control on a page. That seems to me to be what Monorail requires and which you seem to be acknowledging.

Today MonoRail/RoR approach is to give you a canvas so you can start painting on it. That means you have to hand write html, after all what kind of web developer are you if you can’t stand html? A drag-and-drop developer, I’d say.

That being said, I do think that jdn has a point. And that’s why I think MonoRail should offer an alternative. Sometimes I want to craft my UI, sometimes I want to just be fast and get something working real quick. I wrote about some of these ideas earlier.

I’m playing with these concepts and I think I can come up with a ViewComponent toolkit for YUI and another one for Ext-js. However those wont be declaratively configured, but more about this on a future post. I’ve also started to discuss with Ayende an impediment that we have as ViewComponents don’t have lifecycle (thanks goodness), but I’ll leave this one for another day too.

Regarding the concerns, Tim Barcz posted a few:

Are base class library tools (TextBox, CheckBoxList, ect) as well as third party tools (ie. Component Art or Telerik) no longer available? If they’re no longer available are the counterpart offerings as good as what is offered using WebForms?

For the standard stuff (textbox, checks) you should rely on the FormHelper and possibly other helpers. That’s all you need to use. Now we don’t have anything similar to what ComponentArt or Telerik provides out of box. Now, seriously, I’ve worked on a project that the webforms counterpart relied heavily on ComponentArt. It was a breeze to get the same effects using pure html, css and some minor JS. I built them as view components so I could reuse on the rest of the project.

It would be good, though, to have ComponentArt and Telerik interested in offering a packages targeting MonoRail.

Ajax? Seemingly ASP.NET Ajax is out if you go with MonoRail, so what to use instead? Has MonoRail adopted one of the javascript libraries as it’s main provider for javascripting/ajax? If so how does it compare in ease of use when compared to ASP.NET Ajax?

MonoRail bundles the prototype library and offers the AjaxHelper. I’m fond of the prototype library, but others are using jQuery, moo, and other libraries with MonoRail with no problem whatsoever.

Comparing them can be difficult. I havent used ASP.Net Ajax for anything serious, but rest assure that you would have to type some JS to get something done with Ajax on MonoRail, instead of just dragging, setting some properties and leave it up to some crazy infrastructure to pull the right strings.

Af first glance, there also no longer seems to be ways to use server controls or user controls? Is this statement accurrate? If so what is the proposed method of getting the same functionality.

MonoRail comes with a few ViewComponents. There’s also the contrib project offering more. If you just want to reuse some piece of view (no server side logic) use simply partial views.

32 Responses to “The usual FUD about MonoRail”

goodwill Says:

wow cool looking new theme!
Ok on the topic:
I still don’t understand why people feel so much about web controls. You got to test the water before you say you really can’t live without them. Seriously, many big ASP.NET project relies heavily on custom JS and their home brew components. The way how ASP.NET handles the ‘canvas’ is too inflexible and you have seen terrible JS integration all around with ASP.NET. Why you have to guess what is the row ID if all you write is just #foreach (item in items)

I just think this is way more predictable. And not to mention the very stupid broken way on doing validation relies on web ui level element instead of roles from model. You got much longer way to go in order to make your UI with reusable validation from model if you are using…

You honestly don’t need web control, IMHO. Website are mean to be really different in most cases, web form’s way just making things really ugly.

macournoyer Says:

I know I’m repeating myself, but Rails has solved the “starting quickly” problem with the code generator. Please no GUI wizard or drag and drop interface. Leave this to the webform world.

And wtf if you consider yourself a developper and hate writting code and markup ?!? If you prefer drag & drop from coding maybe you should consider switching job or learning a new, more fun, language!

Brad Says:

I haven’t checked this out yet, but I recently came across some open source ajax controls for 2.0. I wonder if they could be used easily with MonoRail?

Colin Ramsay Says:

Some of the comments on Ayende’s post are making me absolutely cringe. It seems that so called “web developers” are adverse to working with HTML – the basis of the entire web platform.

To me this is a prime example of why Microsoft’s approach of abstraction in WebForms is fundamentally wrong. Hiding basic code behind a drag and drop interface is cultivating a culture of ignorance.

Andrew Peters Says:

The fundamental thing people seem to miss about this is that web design (and ideally HTML production) should be done by a _designer_.


I agree with Marc-André, if people like drag and drop development, they have to pay for it in performance and flexibility loss.
The power of monorail comes for example when you can add a user to your database in one line of code on the boo console.
I think the best way for people to understand MR is through ROR because they won’t try to compare it to WebForms as it is something different. Also Rails has a lot more documentation, books… and ROR is a perfect example of making development easier.
Then when they realize what ROR is missing compared to the .NET libraries, they will think MR has some of the best of both worlds.
One thing MR is missing from ROR is the plugin system. (Plugins often contain generators, controllers, helpers…)
View components solve UI problems, plugins can do more.
In particular, it would be nice to have a plugin providing rapid integration with the .NET Membership API as it is a part of most applications.

hammett Says:

Says who, Andrew? I’m not a designer, but I’m comfortable with css and html.

jdn Says:

Thanks for the discussion, I appreciate it. I still get a childish visceral thrill when I see my name in ‘print’ even when I’m being called a douchbag (I heard that…LOL), but I’m looking forward to see what the alternative ends up looking like.

I’ve posted a long-ish reply here:

But basically, the whole ‘he must be a drag and drop designer’ is way off base.

Trying to remember why you would know I have a Ph.D. (it’s in Philosophy so it’s either a great accomplishment or totally useless…I’m thinking both). Must have been Bellware’s BlogCoward stuff.


jdn Says:

Not that you were calling me a douchebag here, of course.

I think…LOL.

Thanks again. And I’m not just saying that because you said I had a point, though I do appreciate that.

Pedro Teixeira Says:

jdn, I think you’re only looking at the view engine. But there is much more. Monorail is a MVC framework. Have you seen the Microsoft Web Client Software Factory (Acropolis in future) alternative? It’s rather complex (really complex), and it still does not provide a easy reverse-data-bind to objects from the web controls. (you can always write code for that, but Monorail has already done it).

In the webforms/code-behind pattern, it’s really common to see terrible code. With Monorail, you can limit what developers can do in the ui part of the app. Also, from a market point of view, it’s much easier to hire developers familiar with HTML/CSS/Javascript than developers who understand about ASP.NET 2.0 (not many people do) – I work for a software house where it’s also an advantage to use Monorail in order to facilitate developers with a java background working in .net projects.

One has to remember that html is what it’s being sent to the browser, and webforms put you really far away from the target infrastructure. People should remember that html was not invented to build apps and to build rich UI (with complex events) you should consider something else like Silverlight / Flash / lazlo or a desktop smart client (Win32 or WPF) (I know clickOnce is worse than java web start but it’ll get better).

Steve Gentile Says:

I’d like to write my javascript within script tags, not tied to the server side technology outside of perhaps attributes on controller methods that would help assist with ajax related calls.

I think Monorail should strive to be ‘js library agnostic’.
ie. I’d like to use ext js instead of another library. I should be able to simply do this in my html script tags :)

(I think the only ‘hook’ is for the ajax stuff personally)

Steve Gentile Says:

I don’t think any ‘real’ developers work strictly in ‘drag n drop’.

I’ve noticed some of the anti-MS developers like to make comments like that. It’s a shame, some ego boost for them I imagine?

Truth is, typing in table tags for 3 hours vs. dragging a table out to the UI – can be considered making good use of components in the OO UI world. I see it both ways. The key is: do you know what it produces?

Let’s not pigeon hole developers so quickly please – people are all at different levels of experience out there.

Andrew Hallock Says:

I’m hungover, so this is going to be glib and mean:

If you’re developing for the web, you should know the various HTML and CSS specs inside and out and be fluent in Javascript. You should be able to open your favorite text editor and create an entire HTML document with no assistance.

Not having enough time is a sorry excuse. Expecting gratuitous layers of abstraction to fill the void in your knowledge is lame.

Knowing these dirty “low-level” layers is necessary because of the direction web-based apps are headed. Think semantic. Web forms is not it.

You can still automate HTML generation through code snippets, code-completion, templates, or any of the various tools at your disposal. So what, really, is the big f-ing deal?

Tim Scott Says:

Two perceptions about Monorail that I believe are wrong:

1) Monorail has a bigger learning curve than webforms
2) It takes more time to to develop rich UIs with Monorail than webforms

On the first point certainly drag and drop development requires a low learning investment. However, this approach very quickly comes to collision with the details of the underlying HTML and HTTP. Skilled webforms developers know this and over time make a big learning investment to understand, as best anyone can, what webforms are really doing. Over time they develop a command of webforms. I suggest achieving proficiency with Monorail requires a shorter learning curve than for webforms.

On the second point, drag and drop development gets things does quickly. But again, this approach quickly runs aground. Who among us has not spent a half day pulling their hair out to find the one server control property 5 levels deep in the object model that will produce the behavior we desire. Maybe you can’t figure it out and do some hack instead. To do what you really want, I believe that webforms is not a bargain in terms of time efficiency.

Jay R. Wren Says:

I think all of these complainers need to be referenced to the many writing on WHY MonoRail was created. “How do I use usercontrols?” in the context of Webforms assumes that this is something one wants to do. The entire premise of MonoRail is that Webforms are broken. It follows that usercontrols and anything else webforms is broken as well.

I’d just point them to the docs :)

Tim Barcz Says:


Thanks for answering my post, I’m grateful you took the time. You’re a great salesman not by the words on castle’s website or here but by how well/easy things worked when I cracked open MonoRail.

The ease in which things went together has caused me to think about looking into Windsor and how that can fit.

Overall, despite my newness to MonoRail, I’m not new to the ideas MonoRail is designed by. It’s wonderful and thank you Hammet for your post!



jdn Says:

I agree with Andrew, you should know HTML and CSS and (if you have to) Javascript inside and out.

And then never have to hand-type it unless necessary.

Steve Gentile Says:

I would like to see jquery and ext with Monorail :)

Stian Solberg Says:

I’m one of the developers behind Gaia Ajax Widgets, which was mentioned above in the comment from Brad. The library is built completely from scratch, but with inspirations from e.g. Anthem.Net. R.I.P…
Some of the benefits of our open source library Ajax library for ASP.NET 2.0 are:
* No need to write Javascript
* No need to write Web services to get the Ajax working
* No ScriptManager
* No changes to web.config
* No UpdatePanels
* No configuration
* 100% Mono Support

The library is built with Prototype. It does Ajax “the real way” by updating the properties of the controls on the browser, and does not send HTML in most cases.

It would be cool to see if we could be the missing Ajax link for MonoRail… Please contact us via our web site if some of the MonoRail team are interested. :-)

Whyrun Says:

To the “what kind of web developer are you…” snipe, I’d respond by saying “a more productive one.” I’d agree with the other posters here like Steve Gentile about you being quick to pigeon-hole just because you (and Andrew Halibut it seems, the name seems fishy to me) like to spend your time typing in HTML. You and fishboy are welcome to notepad to continue to demonstrate your mastery of jscript and HTML and improve your typing skills. I type just fine thank you very much. Oh and if Andrew Haddock can tell me how typing in low level jscript and HTML gets us to the semantic web and using more productive tools doesn’t, I’m all gills, er, ears.

Janne Majaranta Says:

Well you don’t have write HTML in notepad
(or at all) when using MonoRail.
You can use your favorite WYSIWYG HTML Supah Tool
to do the drag-and-drop dance if you are happy
with the output produced by the editor.(For example in VS.NET 2005,using NVelocity templates, register the *.vm extension with the VS.NET html editor, and voila, instant drag’n'drop)

This is not exactly true for webforms. Not many WYSIWYG
HTML designers support the full aspx set of of tags.

I think this discussion has gone way off topic to discussing
tool support in terms of writing plain HTML or using a tool to
design the HTML (which aspx produces anyway…).
This argument does not stand. You can use a tool to visually design both, aspx and html (nvelocity), if you want.
For web-projects where accessibility and standards-validity has
to be considered, or the UI design is outsourced, plain html designed by a experienced designer doing only html designs is the template for the UI anyway. Renaming the .html to .vm and filling
the placeholders with VTL is probably easier
than trying to identify which visual elements look like a
specific webforms control.

Oh btw, We have been using jQuery with MonoRail since we
started using MonoRail (about since 10 months). Mainly because jQuery is so easy and wrist-friendly. We have written a helper
for the most used jQuery calls originally, but now as the
application (and knowledge) matures we are talking about if abstracting JavaScript
is a good thing… Why not let JavaScript be JavaScript and
why fight it ? ;) Writing just the JavaScript has opened a very different view on the language. JavaScript is a very powerful
language. Also, tool support is better when you just write the JavaScript (Ever tried Aptana IDE ??).

Now, could the discussion possibly go back to leaky abstractions ? ;)

Thomas Hansen Says:

I’d normally don’t answer postings that have religious facets, but I think I just have to comment on the parts where it’s being pointed as a choice between either “drag’n'drop” or JavaScript…

WebForms and WebControls has as little in common with drag’n'drop as a wheel has with a car. Sure a wheel can be used on a car but that doesn’t mean that a wheel is a form of a car!

Using WebControls instead of JavaScript and HTML + CSS is a choice between writing declarative and abstracting away the difficult parts or writing detailed and being 100% in control at the cost of efficiency!

It’s basically the same discussion the programing community has had ever since we started moving away from punch-cards and moving onto assembly and then again moving away from assembly and onto C, from there the story just repeats itself into eternity!
The abstractions gets better and on the road we loose control and some few CPU cycles. Still nobody would today consider writing a web application in CISC x86 Assembly code though it by definition HAS to be the definitive fastest and most optimal way to do it…

It has nothing to do with drag’n'drop it has though all to do about writing declaratively!
You know you want to have a DateTimePicker, then add up a declarative tag that will render a textbox which when clicked will popup a Calendar from which you can click dates within. That is declarative programming! It is also pretty nicely related to AOP too…

Sure it will make you loose a couple of CPU cycles and you probably could hand-roll a way faster solution on a basis of needs, just like you also definitely could write a 100 times faster application using Assembly! Though how often do you care if the popup to choose dates needs 0.01 second to show itself and uses 0.1 MB of RAM or if it takes 0.00001 second and uses 0.0001 MB of RAM…?
My answer so far (25 years of development in about 50 different programming languages) has always been so far; “almost never!”

It’s all a matter of taste combined with the problem at hand!

But for most solutions MORE abstraction is BETTER…!


Dave Says:


In the web development domain: jQuery, ExtJS, scriptaculous and prototype (i.e. javascript “abstractions”) are much easier to use to their full potential in a monorail application than in a webforms application, because it is so much easier to deal directly with the http request/response architecture that is the basis of EVERY web app. WebForms breaks many common conventions of web development to support its “VB-on-the-web” mentality.

What’s the id of that LinkButton nested in the Repeater, again?

Another great “declarative abstraction” that is made much more difficult by WebForms world is CSS selector syntax. Heavens…

Note that MonoRail provides a level of abstraction that is helpful _but_no_more_. You are free to build your own site- or domain-specific abstractions and use them… which is not possible in WebForms because you are tied to a fundamentally broken architecture.

You imply that performance is the goal of a framework that lacks this (leaky) abstraction, but this is purely a straw man. The reason for choosing MonoRail has nothing to do with performance and everything to do with the effort required to build equivalent functionality. The performance differences are just gravy.

Plainly stated: in my opinion, based on personal experience, it takes less effort to deliver a non-trivial application using MonoRail than to deliver the equivalent application using WebForms. This difference seems to become greater throughout the lifecycle, as the project becomes more complex, is released, and maintained through multiple revisions.

There may be other reasons to use WebForms in a particular environment (leveraging shared code base, developers that are more familiar with it, etc), but I firmly believe that MonoRail is a more efficient solution, effort-wise.

You know what else? Monorail is just plain _more_fun_ to work with than WebForms. Much less time is spent fighting against the framework.

As to your DateTimePicker example… this is only a few lines of code in Monorail. Note that WebForms is not magical here: there is already a declarative syntax for “TextBox”: the html input tag. Monorail provides you a one-line solution that not only creates the textbox (using FormHelper) but also “data-binds” the value both ways (to the view and also back to the server on post).

Also, note that there are many easy-to-use, good free Calendar js libraries available. Building a view component to encapsulate one of them is at most an hour of effort, should you choose to.

One other thing about WebControls: The easy-to-create “declarative” (i.e. markup-based) type of WebControl is a UserControl. But UserControls are inherently unsharable between projects without some Virtual Directory hackery… So, to create your own WebControl that can actually be included in a library and shared across multiple projects you must resort to writing HTML to a stream.

One other minor quibble: writing in x86 assembly is not necessarily the highest performance solution. Some JIT optimizing bytecode compilers (IBM HotSpot for example) analyze and optimize code at runtime based on the actual usage. This runtime optimization, theoretically, provides the ultimate level of optimization, because hand-optimizing asm code results in tradeoffs (size vs. speed most commonly) that are based on speculation. The JIT optimization can take factors into account to parameterize the optimization based on the operating environment and usage patterns. Note also that this is not tied to a specific OS, and that the biggest optimization of all is to deploy your application to a faster machine (i.e. possibly a different architecture… not possible in x86 asm)


Thomas Hansen Says:

Thank you for a thorough and very detailed reply though you do make a couple of assumptions and miss to see some of the good features of a WebControls/Forms solution…
The most important aspect with the semantic web is that from any “event” (e.g. click LinkButton, Button or select new value from a DropDownList(select HTML wrapper)) you can do everything you want to. Including but not only showing a modal window, creating another dropdownlist to drilldown a selection, change an image etc…
I don’t know if this is possible to do in MonoRails but I doubt it is possible to truly do in a framework that doesn’t fulfill a “full Page Cycle”…

Look at the code for this sample for instance;
A complete chat client with less then 130 lines of code and not only but there is only ONE programming language involved. No need to train junior developers into developing utilizing JavaScript which is a notoriously difficult language to learn and NOT the language of choice to have business logic in.

Or look at this;
U complete “pain shop” (well, not exactly, but you get the idea) with 131 lines of ONLY C# code…!
Not ONE line of JavaScript…!

Or this one;
A tab control created from building blocks like MultiView, Buttons and Window.
100% declarative, 100% C#, ONE programming language and NO business leakage out to the client in forms of business logic in JavaScript…!
Virtually impossible to hack (crack is though the accurate word here) too…!!

And regarding UserControls as the only solution to reuse code…?
Then you should take another look into inheriting from WebControl, Control or even any of the Gaia Controls…
UserControls is by FAR the only solution for re-use in webforms…!
But I know too little about MonoRails to state that WebForms is better (or worse) but I do know that many of the assumptions are too fast in your reply to mine… ;)


Dave Says:

Thomas, those “no-javascript” examples include around 20 javascript files (including prototype and scriptaculous which are the two JS libraries most commonly used with MonoRail).

Reading through the Gaia javascript used in those examples demonstrates many of the work-arounds that are necessary to code in javascript in a WebForms application.

Re: UserControls, re-read my post. I said that UserControls are the “declarative” form of WebControls… i.e. driven by markup… they are a major PITA to reuse. I am aware that there are other ways to create a control.

Other WebForms gripes (I’m sure these are covered in much more detail elsewhere by developers more informed than I am):

WebForms tightly couples the view and the controller.

WebForms makes testing the web application logic much more difficult.

WebForms produces bloated HTML and makes it harder to apply CSS consistently due to its ID-munging.

Ditto for automated web testing.

Ditto for javascript. Especially ditto for javascript.

Cross-page post anyone? The page that is being posted to has to know about the type of the page that is being posted from? WTF?
Anyway, I feel like I constantly fight against the framework when I am working on a WebForms project (currently I am working on 3 projects, 2 that are WebForms-based, one that is MonoRail).

I also am annoyed with some aspects of MonoRail, however, very rarely is there an annoyance that can’t be worked around. I have not yet touched a line of Castle Project source either… which is always an option as well.

I have not read many (any?) “WebForms is better” opinions from developers who have actually worked on serious projects using both frameworks. I have worked on large .NET applications using WebForms, custom solutions built on the ASP.NET architecture but not using WebForms, and MonoRail solutions.

Basically, I feel that the amount of work saved by using MonoRail is greater than the amount of extra work required, relative to WebForms. Also, I believe that the savings margin increases over the lifetime of a project.

Anyway, I would encourage you to install MonoRail and create a project. It really is a fun platform to work with, and free from many handcuffs, chains, and other WebForms-imposed impediments.


FreeChickenNBeer Says:

Regarding the comments from Thomas:

I’m sure I’ll get slammed a little for this but oh well…

I think you have it right. I’ve been a long time developer, uh, I mean “WebForms Developer” (better update my resume), and that does not imply that I have ever used drag-and-drop for anything. On the contrary, I rarely use drag-and-drop for anything. I actually know HTML, CSS, JavaScript, etc and use it daily. Actually, more of my work involves architecture, object modeling, database design, patterns, but I digress…

I’ve recently been exposed to MonoRail at a new position, and although at first I was a little shocked at the paradigm shift, so far I am hesitantly impressed. There are some really cool features in MonoRail that MS should definitely integrate into

At the same time I feel that some people can take the MVC pattern/implementation a little too far – over-architecting for the sake of architecture itself. Some applications don’t deserve a full MVC implementation. And some developers are surely using MonoRail solely to prove a point that they are hostile toward MS and want to look “cutting-edge”.
WebForms in themselves are not necessarily bad design. Separation can still be achieved with proper architecture. These broad generalizations are to be expected however on a blog of this nature. If you don’t understand the page life cycle, you obviously haven’t done much serious work with webforms.

My main objections so far with MonoRail are the lack of 3rd party controls/suites targeting it and the FACT that MS and WebForms is much more of a defacto industry standard for enterprise .NET development. How many large companies are going to want their site written using MonoRail when there are substantially fewer developers proficient in it (obvios understatement)? What happens in a few years when newer versions of come out with different presentation methods? In my view the goal of software development is to provide a cost effective, scalable, maintainable solution to a customer’s business problem, not to satisfy the programmer’s ego or play around with alternative technologies for the sake of learning on the job.

Consider me a sellout, but MS pays my bills. I’ll give MonoRail a shot, but I still remain skeptical.


Michael Says:

Our development team NEVER use designer for ASP.NET development. I am stressing that. We NEVER use drag and drop. Why so many people think that MS ASP.NET == DnD development?

ASXP/CodeBehind/UserControls/ServerControls concept works great for our big project. And I really wonder why anyone can prefere ASP-way to ASP.NET way of development.

I used to code on PHP several years ago as well as Perl (I’ve started from PHP in fact) and should say that ASP.NET concept is much more manageable in a long term. It is possible to create elegant architecture on PHP for sure, but in ASP.NET it is simpler.

I found that Page Controller pattern works great for web applications and do not see much value in MVC in fact. Maybe that is the reason I don’t see much value in MonoRail.

Kevin Says:

Hi Michael,

It’s interesting to see a post from you on this discussion. I am both a customer of your product (TargetProcess) and a developer using MonoRail working with the Castle team.

The main benefit of MVC is separation of concerns. The nice part of MR is that it lets you implement the MVC design pattern and keep most of your application in standard .NET. Your data layer, services and business logic are still in C# or VB.NET and your presentation layer is whatever template engine you choose (NVelocity, Boo, WebForms or a composite of multiple engines).

In truth, there are pros and cons to both methodologies.

WebForms Pros:
- Lots of 3rd party components available.
- Lots of documentation / support forums.
- Compiled / cacheable (good performance).
- Design time support (love it or hate it).

WebForms Cons:
- Bloated client-side code (bad for SEO, slower client downloads, heavier bandwidth).
- Often requires jumping hoops for the postback lifecycle (including going through the entire lifecycle for an AJAX UpdatePanel callback).
- Forces creation of server-side objects out of client-side objects and abstracts/obfuscates simple elements.
- Often makes JS implementation harder than necessary.
- Makes it easy for newbies to combine all tiers into a single aspx.

MonoRail Pros:
- Allows you to streamline client-side code.
- More intuitive to developers from non-webforms environments (Classic ASP, ColdFusion, PHP).
- Enforces separation of concerns. Promotes multi-tiered application design.
- Allows extensive flexibility for swapping out the presentation layer (which our app requires).
- Simplifies “binding” of server side data and objects to the presentation layer.

MonoRail Cons:
- Lack of supported 3rd party controls (granted, there are some good JS / Ajax libraries out there).
- Lack of documentation / support forums (they exist, but there’s not as much support as ASP.NET).
- Some view engines aren’t compiled (i.e. NVelocity), though better caching is being implemented.
- Lack of design-time support.

Coming from the WebForms world myself, I too shared your skepticism regarding MVC and MR. The Castle team has been working with my company over the past year, and we have implemented an impressive web application with ActiveRecord and MonoRail (NVelocity). In particular, our solution has an extensive themes/skinning solution with portlets. We have a single codebase that is serving custom websites for numerous clients.

The presentation layer is so well decoupled that every website is truly custom. We were able to extend the NVelocity engine to automatically swap out pages and partial pages based on the theme setting for a site. Furthermore, our customers have significant control over the presentation, including insertion and configuration of portlets in designated slots (which can be defined uniquely for every site or customer). Our CMS also has the ability to spawn hierarchies of virtual paths on the fly without any URL rewriting plugins or persisting anything to the file system. For instance, when a user adds an article, we have a virtual address of /articles/category/subcategory/myarticle.rails. That’s excellent for SEO and “hackable” url’s.

In short, I believe that our use of MonoRail made it much easier to implement a level of flexibility in presentation that few web applications could match. Accomplishing the same thing with WebForms would have led us down a much more complicated path ultimately producing something similar to DotNetNuke (jumping the same hoops of trying to manage page state when dealing with dynamically injected modules).

In other words, give it a chance. It’s a paradigm shift. Depending on the goals of your application, it may make sense, it may not.

Zen and the art of Castle maintenance » Blog Archive » In regard of MonoRail and WebForms… Says:

[...] of our clients – which btw is with us since we started — decided to comment on that flamed thread in response to a Michael D. comment. I rest my [...]

Aaron Says:

Try PoCoRail and get the best of both worlds…


Richard Says:

I think the relative merits of MonoRail vs WebForms is clear. In the end, when making a technology choice, it’s like any other business decision, in which you weigh the cost, benefit and risk of one choice over another. Some people NEED an MVC… and some people can live with (or maybe even need?) a Page Controller.

One of the key components which led me to Castle in the first place was the MicroKernel. I needed an Inversion of Control Container and Dependency Injection… and I needed them in a straightforward environment where I had total and complete control over as much of the technology stack as possible. At the time, StructureMap (on top of ObjectBuilder) just didn’t have the depth I needed (ObjectBuilder was just coming out) and Spring.NET relied too heavily on Xml. I didn’t even know MonoRail existed until I investigated the DynamicProxy. I mean… the DynamicProxy. The last I looked, this little gem is a dependency for at least two other Open Source .NET projects (Spring.NET and NHibernate).

I’ve done a little digging, and this discussion about MonoRail vs WebForms has been going off and on for quite some time… since MonoRail’s inception, if I’m not mistaken. I love the discussion, because as much noise as it may generate, it is causing more and more eyes to look at the Castle Project as a whole… and this is a VERY GOOD THING.

The Castle Community would serve itself well if we refused to agree to the premise of the argument about WebForms vs MonoRail; that you must choose between them. Those folks who simply cannot live without WebForms can have WebForms with the WebForm View Engine. Lets reframe the discussion, by opening it up to the more general topic of “Why Castle?”.

Andrew Davey Says:

I remember reading this post or something similar probably 4 months ago (actually I think it might have been longer)…in any case….my initial reaction was….’wtf?…I can’t use server side controls….or my telerik controls……that’s taking a massive step backwards.’ Or something along those lines.

At the time I considered myself an ASP.Net expert (I may still be…but it’s been five months since I’ve done any serious ASP.Net stuff). I wrote my own controls. Was all down with the page life cycle, and the model that Asp.Net uses in general.

When people wrote ‘the lifecycle is too complex’ I used to think ‘big babies’. I honestly thought that there was no better solution to writing a large web application than Asp.Net.

Then in July I had to lead up a new project to be written in ColdFusion (shudder). (The goals of the project were/are pretty ambitious, and to be honest, using Asp.Net’s compilation model, I’m not necessarily sure it would be viable to have done the project within Asp.Net).

In any case, I knew that I didn’t want spaghetti code all over the place, so I searched for a framework in CF that would keep most of my code out of the html. I tried Model Glue:Unity, read up on Fusebox and thought that both were a waste of time.

I then stumbled across a small, incomplete framework called CFWheels, which is basically a partial port of Ruby on Rails. It was then that I finally saw the MVC light.

I guess up until that stage, I just didn’t ‘get’ MVC. Splitting my work across three files seemed like some much extra work, plus there is all that html that you have to write to replicate Asp.Net control.

But man the control that you get. The cleanness of the code. The ability to have more than one form on the page that can post data. There is nothing not to love.

MVC made Coldfusion manageable, and in fact, CFWheels + ExtJS + Eclipse + Hibernate + JSON JSON JSON (I love dynamic languages now) has made the project a joy to work on….very clean and simple to maintain. Plus it’s fast to develop in. If you’ve never stepped outside of VS (like me) then you could be forgiven for thinking it’s the best IDE out there. But it’s not. Man is it slow. Slow to start, even slower to debug…but I digress.

I guess the point that I would like to make is is this. It’s difficult to convince people of MonoRails merit if they don’t see the value in MVC. If you’re not an MVC advocate, you feel like you are taking a step backwards, not forwards.

Once you’ve seen the MVC light, then it doesn’t take you long to gravitate towards the ‘rail like’ frameworks. In CF land, ModelGlue:Unity and Fusebox are very popular…but personally…I think their so bloated with xml configuration just to get them to work. I much prefer the convention over configuration principle.

So I guess the question is….how do you spread the light?

How do you convince someone that coding up a web application in MonoRail isn’t going to require you to break out the debugger everytime one of your pages doesn’t render just quite right.

Or that adding complicated controls is a snap since you are working in a framework that encourages javascript as opposed to punishing it (getElementById(”) anyone?).

Leave a Reply