MVC or MVA? Or, What Do Controllers *Do* Anyway?

<< (More) Kudos to the ASP.NET MVC Team | Home | BDD: Coming to a Theater Near You? (Tonight!) >>

MVC or MVA? Or, What Do Controllers Do Anyway?

posted @ Monday, February 18, 2008 8:46 PM

I've been looking at and working with Model-View-Controller frameworks off and on for a couple years now, from Rails to Monorail to ASP.NET MVC. I've been taught that the Controller is a first class citizen, responsible for application flow (at least handling request/responses) and rendering views, etc. The Controller gets its name in lights, right next to the Model, and the View.

But what does the controller really do? By far the most popular pattern is for controllers and their actions to map to URLs such that /people/list maps to a PeopleController's List() method. So, are controller's just "Action aggregators?" Are they basically namespaces for URL pattern matching (i.e. /[controller]/[action])?

While this was probably not the original intention for the pattern, in practice it seems to be the case. Further spark for this line of thought for me was hearing JP Boodhoo describe how he implemented a simple MVC framework that was basically a Command Pattern. JP's implementation matched requests (url + payload parameters) to a command, which handled the request and, if necessary, to a view that would render the results - bypassing the controller completely. Monorail's Dynamic Actions approach this pattern by creating Action objects, that can be indexed to an action name in a controller:

public class MyController : Controller
{
    public MyController
    {
        DynamicActions["index"] = new IndexDynamicAction();
    }
}

The Controller/Action paradigm also brings some baggage when it comes to actions that are similar or shared across several controllers. Controller inheritance can get real ugly real fast. Hammet and others have sung the praises of Dynamic Actions to alleviate some of these issues, but to me, it begs the question, "why not just throw away controllers altogether?"

I wonder why we don't just focus on the Routing infrastructure to map requests directly to Actions and Views, which are the real "players" in the system. This would allow for easy Action reuse, aggregation, inheritance, etc - all the benefits of the Command Pattern.

When I get a chance to get back to some real coding with any of the MVC frameworks I've used, I hope to experiment with this and see what I can come up with.

In the meantime, I'm curious to hear other people's ideas on the value (or lack thereof) of the Controller in MVC?

Comments

Scott Bellware
Posted on: 3/18/2008 11:54 PM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
Brian,

> I wonder why we don't just focus on
> the Routing infrastructure to map
> requests directly to Actions and
> Views, which are the real "players"
> in the system. This would allow
> for easy Action reuse, aggregation,
> inheritance, etc - all the benefits
> of the Command Pattern.

Controllers are naturally cohesive around resources. They are the abstractions that represent resource points in a resource-oriented web app.

It makes much more design sense to have a CustomersController with a Create action, an Update action, a Show action, etc, than to have dis-encapsulated CreateCustomerAction, UpdateCustomerActon, ShowCustomerAction, etc, classes.

We have controllers for the same sensible reasons that we don't code every method in an object system as a command pattern: responsibility (which is a perspective of cohesion, or vice versa).
Brian Donahue
Posted on: 3/19/2008 11:29 AM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
Hi Scott,

That makes sense regarding resources, although I'm still not sure a Controller class is the best/only way to group those actions by resource.

But other functionality such as authentication, and complex view rendering actions seem to be bogged down by controller constraints.

Maybe I'm throwing the baby out with the bath water - but I do want to experiment with some other organizational and routing structures for mapping Actions to requests and see how they feel.
Jeffrey Palermo
Posted on: 3/19/2008 5:02 PM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
In my opinion, the merits of the MVC pattern aren't at stake. This organization triad has proven itself worthy of existence. In procedural programming, a method can stand alone, but in OO, every method should be a part of a class. I'm not sure what you are proposing, but even if you used the command pattern take on a controller (just an Execute()) method, you'd still have an action method named "Execute" and a class that inherits from IController. I don't quite follow what you would rather see.
Brian Donahue
Posted on: 3/20/2008 6:14 PM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
Hi Jeff,

Granted, Action classes would need access to many of the same assets that a Controller class has. Not sure an Action would need to/want to *inherit* from Controller. I am not saying MVC is dead, or even devoid of value, I am just wondering if a slightly modified architecture might provide additional benefits, and thinking maybe it would align with the way I think about building web apps better. I'll have to mess with it, and see if my experiments prove out what I'm thinking. I'll surely post whatever I come up with, as soon as I get the chance to dig in.
Craig Wilcox
Posted on: 4/23/2008 4:44 PM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
I've been exploring the ASP.NET MVC framework lately and, unless I'm missing something, the framework's routing infrastructure does, indeed, "map requests directly to Actions and
Views". And (ala Jeffrey Palermo) those action methods have to live somewhere and that somewhere is a controller.
Of course you'll get your reuse through supporting classes that all controllers can access.
Brian Donahue
Posted on: 5/20/2008 3:04 PM
# re: MVC or MVA? Or, What Do Controllers *Do* Anyway?
Hi Craig,

Just noticed your comment.

The difference is subtle at the surface, but routing points to a controller, and an action. I am speculating that grouping by a controller doesn't really provide any additional value, and causes some friction when we want to reuse actions, or extend them. If actions were objects, rather than methods on a controller, this could be avoided. We could still group them via routes so that REST and other common url patterns were still used, and we'd get the full potential of an Action object model for reuse, and extensability. I need to find some time to play with this so I can prove out my thinking and see if I can come up with something that might be useful. But Monorail does have something pretty close with its DynamicActions.