Controller bloat?

Some of my background information first:

  • 2 years classic ASP (ASP 3.0)
  • 5 years ASP.NET
  • 1-2 months MonoRail
  • 10 minutes ASP.NET MVC
  • ~45 seconds Ruby on Rails

That’s the sum of my experience with different web application frameworks.  Obviously it’s weighted towards ASP.NET WebForms.  Having completed a project with MonoRail and looking at ASP.NET MVC, I can’t help but feel that the Controller and the accompanying Context objects seem bloated.

Now, I’ve already shown I’m no MVC expert, not even close.  But this seems a little bloated for something that’s supposed to be lightweight:

Sorry about the size, but it’s nice to see it in all its glory.  That’s the MonoRail Controller and RailsEngineContext (the HttpContext-like object of MonoRail).  Controller depends quite a bit on the IRailsEngineContext, so you can’t really do much with a Controller in a unit test without mocking out the entire IRailsEngineContext and all of its properties (IResponse, IRequest, etc.).

Here’s the ASP.NET MVC Controller and Context from the Preview 2 drop:

The Controller is smaller, but the Context is larger.  Again, the Controller makes heavy use of the HttpContextBase (formerly IHttpContext), as shown in Scott Hanselman’s recent podcasts.

Having next to zero experience with other MVC frameworks like Rails or Merb, I’m really curious to see how lightweight their controllers are.  I’m not sure lightweight controllers matters, or if the idea of a POCO controller would do anything.  Since we have to inherit from a Controller base class, we’re saddled with its weight.

I’ll repeat again: I’m not an MVC expert.  But these controllers seem bloated to me and their accompanying Context objects seem bloated, as if I need to give the controller the IKitchenSink to get it to work under test.  Does anyone else get this feeling too?

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in ASPNETMVC, MonoRail. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Colin Ramsay

    The trunk version of Monorail has been heavily refactored in that area, and may address some of your concerns. I haven’t used it but it may be worth your investigating and doing a followup….

  • In Monorail there is a BaseControllerTest in the Castle.Monorail.Framework.TestSupport namespace that mocks out everything you need to perform unit tests on monorail controllers. Not sure if you saw that or not.

    As far as the bloat, as you noted with ASP.NET as well is I think some bloat in this area is necessary. Perhaps some of the methods on Controller are now unnecessary and have been removed, but the majority of the properties on Controller are necessary. Perhaps the current refactorings on the trunk have removed some unneccesary members on the controller/enginecontext classes.

  • Thomas Eyde

    In ASP.NET MVC, your controller need only to implement the IController interface. But then you are on your own and have to code all the details yourself.

    And I guess that’s why these classes are so big: They contains shortcuts for a lot of things.

  • The monorail refactoring introduced IController…I’d look at the trunk code to represent Monorail correctly.
    You can implement your own IController or simply use DynamicActions for action object graphs.
    I see controller as an 80/20 where it composes a number of services such as Redirection, and so on but the most important thing is how easy it is to introduce your own implmentation of any of them.

    Check out Hammett’s recent post on testing controllers to see how easy it is to test them.

  • @All

    I do know about the test helpers and such. My question is “Are these helpers a smell that the Controller is responsible for too much?” Helpers don’t take away the fact that these controllers are doing a lot.

    So there’s a single IContext, but that has 8 other ISomethings too to get up and running.

    I’ll look at the trunk of MonoRail, but also look at Merb and Rails to see what the differences in _responsibilities_ are.