The state of "web-based" MVC


Over at the FubuMVC camp, the authors of the alternative “web-based” MVC are busy declaring that their framework is the best and everybody else sucks.

There was one particular statement in this declaration blog post by Chad Myers that got me declare “challenge accepted.”

It seems almost every web framework has this wrong: Rails, ASP.NET MVC, Struts, Django, Spring, and MonoRail from my limited research.

Let me put it another way in case I haven’t been clear enough: Inheritance is antithetical to web app design.

One class - that derives from some gawdawful ginormous base class - that has many “action” methods on it is a pile of fail. Why? Because each of those methods has, by definition, a different responsibility and you’re breaking the Single Responsibility Principle. Principles matter!

Chad Myers

Although I agree that the default out of the box experience for ASP.NET MVC is not ideal for the larger web projects, it is nevertheless able to be customized to the attributes desired by Chad. My intention is to demonstrate the following key points in the above qoute.

  1. ASP.NET MVC is not extendable; you have to group actions into controllers.
  2. Other frameworks leave a little bit of a mark against your controller; such as inheriting the Controller base class.

Actions need to be grouped by a controller

The default out of the box experience for FubuMVC is that each “action” only belongs to one baseless class.

However, the ControllerFactory in the ASP.NET MVC stack could still get it “right.” If you prefer one controller per “action” or route, then that is also possible as demonstrated by Jak Charlton’s post.

The Controller base class class

I am a big fan of composition over inheritance. I am also a big fan of the IoC containters. And FubuMVC embraces this. But it seems like that Chad likes it taking it one step ahead of that sweet spot - by only declaring the controllers by convention (for example: the class name being suffixed with Controller) instead of marking it as a Controller by inheriting from the said base class.

One such example of that helper method is to tell the underlying framework of which view you would like to respond with, such as ASP.NET’s View method call. FubuMVC attempts to auto-negotiate on the type of content to be responsed with. This is FubuMVC greatest; it is also their weakness at the same time; which leads me to the next point.

FubuMVC users can never be agnostic about their foundation

FubuMVC tries to sell you the idea that your code would never know about the FubuMVC infrastructure. The whole idea is that an InputModel with the corresponding OutputModel for each Action and auto-wire the response to the content negotiated from the client request.

Yes that is not necessarily true, that is that you are agnostic about the FubuMVC core API.

For example, if you have to have to try get FubuMVC to respond with a HTTP 301 error response such as the following:

HTTP/1.1 301 Moved Permanently
Date: Thu, 05 Jan 2012 21:17:25 GMT
Content-Length: 0
Connection: keep-alive
Location: http://justjuzzy.com/

Now, then, how would you do this in FubuMVC? This blog post demonstrated that you needed the following code in your controller view.

public UserIndexViewModel Cancel(UserEditViewModel userEditViewModel)
{
	_resultOverride.RedirectTo(_urlResolver.UrlFor());
	return new UserIndexViewModel();
}

Another similar example is demonstrated by the FubuMVC recipes.

Again, the selling point of FubuMVC is negated. Why? Because as in this example, your web-based controllers are aware that their client is a web-based view. Because at the end of day, you do respond in HTTP codes with the associated content, whatever it may be: HTML, JSON, XML, and so on.

At the end of the web request…

I love it when new frameworks pop out with newer techniques. Content negotiations and that was a good step forward from the FubuMVC. It is lovely that the other more established frameworks are picking up these nice unique ideas.

Nonetheless, I have to disagree when merit is being robbed. At the end of the day, the MVC frameworks (for the web at least) need to interact with the HTTP client. If you do require other actions or controllers to control the business logic, then perhaps look at the idea raised by Jimmy Bogard.

blog comments powered by Disqus