Development Blog

 Monday, October 15, 2007
« Fluent Fixtures | Main | Campfire and Jacob both rock »
MonoRail vs. System.Web.MVC

So everyone's been talking about the ALT.NET conference, Microsoft's take on MVC, and such, so I thought I'd briefly chime in with my thoughts. Photo 18 First of all, the ALT.NET conference rocked and I'm very much looking forward to the next one. Secondly, I must disclose that Scott Bellware paid me to say that ($1, signed) but I would have said it anyway.

OK, so then there's the whole MVC thing. This too was awesome and I should try and collect a signed dollar from Scott Guthrie. It's obvious he and the team working on MVC are doing their research. That said, as many of you know we're a MonoRail shop here. We've been using it heavily for about a year now and we've got a lot of code written on it. So what will the impending release of the MS MVC framework mean for us? What will it mean for MonoRail?

I can tell you that for us, it will very likely mean a week of exploration and quite possibly followed by a week or two of porting. That's right, it looked that good. Everything about it was done right or flexible enough to be made right so there really isn't any room to complain about it. MonoRail has more features at the moment, but the ones we use wouldn't be difficult to implement on top of MS MVC.

So what does this mean for MonoRail? I can't speak to that, but I will tell you what I would like for it to mean. What I'd like to see is MonoRail become more like Rails. I want to see something built on top of MS MVC that even more-so favors Convention over Configuration--including but not limited to generators and such. I want it to take it to the next level and be exactly what the community wants for a C# web platform. Dave Laribee says that "MonoRail will remain a viable option for smaller or more edgy shops." I think that's true, but I want to see it built on top of MS MVC.

Why throw away all of the framework code built into MonoRail? A few reasons:

  1. Castle has already been experimenting with throwing most of it away and starting over anyway.
  2. MS MVC will be built into the .NET Framework. This means  easier sells to big shops, and MonoRail would be just a free supplement rather than a replacement/paradigm shift, making it an easier sell.
  3. MS MVC appears to be more modular. There is no massive Controller or ginormous SmartDispatcherController. You can even start with a one method interface and implement your controller however you want.
  4. Routing.
  5. It was built with testability in mind. MonoRail is now mostly testable, but it is not nearly as clean as it could be... or as MS MVC's testability looks.
  6. We can probably all but throw away our codegenerator and use lambdas. We could reinvent this for MonoRail in .NET 3.5 but then we'd be... reinventing... it...

Whatever we decide to do when it comes out, we'll talk about our experiences so you can judge for yourself after we judge for ourselves how viable it will be to port from MonoRail to MS MVC.

development | monorail | mvc | microsoft | altnetconf
by Aaron on Monday, October 15, 2007 10:59:24 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [10]  |  Trackback Related posts:
Rhino.Mocks Performance Issue Fixed
Mock Framework Benchmarks
Introducing Machine.Specifications (or MSpec for short)
Mocking Events
Separate Stub and Verify != Duplicate code necessarily
The Past, Present and Future (?) of Mocking
Monday, October 15, 2007 11:35:03 PM (Pacific Standard Time, UTC-08:00)
Interesting point about finding ways for MR to keep being the bleeding edge of ASP.NET

I also think that building upon Ms MVC might be a nice solution instead of doing the whole MR2 from scratch. After all, we are always whining about MS inventing wheels (NUnit/TeamUnit) so it won't be nice (nor smart) of us as a community, to do the same.

As for the CodeGenerator: it'd take some time I guess for hosting companies (and clients) to move to 3.5, so please do not throw that away just now ... :)
Ken Egozi
Tuesday, October 16, 2007 1:29:31 AM (Pacific Standard Time, UTC-08:00)
That sounds... unwise for me.

You are talking about a technology that isn't out yet, and that you have seen in a demo. You compare it to something that is known to work, and that you have a large existing code base in.

The experimentation at MR2 was to build a different internal architecture, it would have meant that most of the code would have moved. Think about it as an architecture refactoring, the code base is very sound. It can be better, but what can't?

Where it the benefits in moving to MS MVC? Routing? You can implement that in a day or two on MR.

In your case, selling to the shop is not an issue, so I am failing to see the advantage here.

This, to me, sounds like a CEO that goes to lunch with a Sun sellperson and come back to say: "We are a Java shop now".
Ayende Rahien
Tuesday, October 16, 2007 3:29:21 AM (Pacific Standard Time, UTC-08:00)
This dovetails nicely with Sean Chambers post on Los Techies (http://www.lostechies.com/blogs/sean_chambers/archive/2007/10/15/yet-another-microsoft-mvc-monorail-blog-post.aspx).

Until we know what the product lifecycle is going to be, it doesn't feel good to give up the ability to get hands on with the framework code to fix bugs or add enhancements. Of course, if the entire thing is "pluggable" with factories + interfaces, such that you could rewrite the entire System.Web.MVC namespace using only MS's IController, IHttpRequest + IHttpContext....then it becomes a little more compelling. This would be my preferred situation, where Castle / MR can simply replace any awkwardly-designed/buggy areas with a superior implementation.
Lee Henson
Tuesday, October 16, 2007 7:46:22 AM (Pacific Standard Time, UTC-08:00)
Oren,

I don't think a CEO switching languages on their shop is a valid analogy. Switching web frameworks is something that can probably be done relatively quickly if the technologies are similar enough.

Obviously I realize most of what I'm saying is conjecture and based only on a demo and an hour or two of 1 on 1 time w/ ScottGu, and I reserve the right to change my mind at any time, but I think keeping our codebase fresh is important.

I'm aware that MR2 was just for architectural refactoring, and from what I've seen, MS went ahead and did that work for us. I haven't yet seen a reason to not build MR2 on top of MS MVC. Without a blocking reason, I think it would be silly not to.

That said, you make a good point when you ask exactly what the benefits would be. Regardless of feature set, I see it as a (potential) step forward in terms of architecture and testability. Yes, my team has been able to work around most of the issues that MonoRail has, but we have used reflection, dynamic proxies and code generation to do so. Not only does that effect performance (primarily of tests) but it leaves me feeling a little dirty inside.

At the end of the day, I don't want our codebase to go stale. I want to continue to innovate on the edge and from what I've seen, MS MVC looks like a good base for that edge. If the Castle project finished writing MR2 in a few months, would you port anything to it?

Oh and, why is dasBlog's captcha such a piece of shit? I had to restart IIS just so I could post this comment.
Aaron
Tuesday, October 16, 2007 8:50:08 AM (Pacific Standard Time, UTC-08:00)
As a developer I want to go where I have the most flexibility. If the architecture of MS MVC gives me that, then that's where I want to be. Right now MonoRail just doesn't deliever that on the scale I want. We find ourselves fighting the implementation and the architecture all too often. If the code is as flexible and well designed as it appears to be, you bet it's a good move. "It can be better, but what can't?" How is that an argument to stay with something with failings? My job isn't to write web frameworks. Sure, MR is open source so you can dig around and submit patches, etc.., but from what I've seen the powers that be don't refactor and redesign as nearly as they need to.

Aaron is right, keeping the source fresh is important. I don't ever want to have a legacy code base. We made the jump from ASP.NET to MonoRail and it was a great decision. If I see something better around the corner I'm not going to shy away because I feel entrenched or tied to the framework I have. We have 10 side projects we want to build to make our lives as web developers easier, if MS MVC is a better foundation to build those, then sign me up.
Jacob Lewallen
Tuesday, October 16, 2007 9:00:09 AM (Pacific Standard Time, UTC-08:00)
@Jacob
Good points there, although as soon as you release ANY code. It becomes legacy at that very moment.

@Aaron
Interesting points. I will definately take a look at MS MVC but I don't think I could justify changing all of my existing projects to a new framework just to keep my codebase fresh. My boss would probably have a cow if I told him that...and I work in education, so it's not even like it is costing money for me to do so, just time and effort.

On the other hand, I am planning on taking a good look at MS MVC and will probably end up using it on any future projects that I work on. Perhaps one or two small ones that don't have a large user base to test it out in the beginning.

As I state in my most recent blog post, the only thing that really concerns me is the community surrounding this framework and how it will differ from MonoRail. I think it will be interesting to see how it works out.

Interesting points though. If you do swap out frameworks you must make posts about how it works out and any caveats you run into. I think that would convince more people to take the plunge.

cheers!
Sean Chambers
Tuesday, October 16, 2007 9:14:33 AM (Pacific Standard Time, UTC-08:00)
I thought the MVC stuff was interesting, but there are way too many unknowns yet to make any kind of informed decision. One of my biggest concerns is that I'm expecting MS to do what they usually do and a) take a long time for an RTM version of this to be released, and b) tie it to some specific framework version. Despite Scott's comments that most of it was straight .NET 2.0 stuff and that it "could be backported", I'm pretty sure they'll eventually make it specific to something like .net 3.5 (if it doesn't delay all the way into .net 4.0). That's already a significant issue by itself (at least for me).

Tomas Restrepo
Tuesday, October 16, 2007 11:21:49 PM (Pacific Standard Time, UTC-08:00)
Jacob & Aaron,

I am not sure that I follow the meaning of stale code.
For me, either the code is clear, expressing the desired intent and malleable to change or not.
Stale is not something that I am familiar with as a term.

You seem to be using this as a way to indicate that you are working on non-new technology (since MR is not old :-) ).

All of that said, you have had issues with using MR, most probably because you are pushing it hard. Your contributions has been much appreciated, and I would like to take this moment to thank you both.
You made my life easier.

Now, as all OSS projects, MR is being driven by the needs of its users & committers. As such, it is mostly driven to solving the pain of the users.
Apparently you have leap frogged us a couple of steps (at least), we are getting there.
Hammett has just committed the initial routing support, and I am working on changing MR to work against IController.

> How is that an argument to stay with something with failings?

It is not an argument to stay with something failing, because I don't think that it _is_ failing.
Ayende Rahien
Wednesday, October 17, 2007 5:21:05 AM (Pacific Standard Time, UTC-08:00)
I guess at this point I don't plan to switch any of my stuff over to MS MVC. I haven't seen anything there that I wouldn't be able to build into MR in less time than it would take to port / test in MS MVC. I also know what Microsoft release cycles are like. In order for me to build RestSupport into MR I needed to make a couple trivial (make virtual and internal to public) to the MR base. If I had been using MS MVC I would have either been plain screwed or have to wait for the next version of Visual Studio (assuming they'd listen to me anyway)
Chris Ortman
Wednesday, October 17, 2007 10:53:41 PM (Pacific Standard Time, UTC-08:00)
That's a very interesting discussion.

I see mainly two directions for this discussion:
one is to follow argument of direct bussiness value, the other is of indirect bussiness value (fresh code base, community, etc).

To begin with bussiness, I found no clear opinion in this post why MS MVC would add any direct bussiness value to your solutions.

If we look at indirect value, Aaron says, that he sees' MS MVC "as a (potential) step forward in terms of architecture and testability". In what aspects is MS MVC architecture more advanced than MonoRail? That's an big question.

The other Aaron's argument is "Yes, my team has been able to work around most of the issues that MonoRail has, but we have used reflection, dynamic proxies and code generation to do so. Not only does that effect performance (primarily of tests) but it leaves me feeling a little dirty inside."
The problem is that tests are having performance problems (any concrete examples for this??) and that MonoRail forces to use reflection, dynamic proxies and code generation. First, reflection and dynamic proxies "problem" is solved by using .Net 3.5 framework instead of .Net 2.0. I don't see how MS MVC helps with that, except that is is built on .Net 3.5. So it I see it as a .Net framework question, and not as a MonoRail or MS MVC. Lastly, code generation will not be gone with .Net 3.5. The code is being generated now, and will be with other frameworks as well, though maybe a little less. (Take for example NNibernate Query Generator, which allows us to refer to class properties with compile time checking instead of using plain strings. Yes, .Net 3.5 helps with that, and we will no longer need to generate as much code as with .Net 2.0. But it is my speculation, maybe i'm
wrong)

Nevertheless, all we want to here is facts and how do you feel about MS MVC, does it work for you, and was it worth moving from MonoRail to MS MVC. Hope to here that.
Darius Damalakas
Comments are closed.