Comparing MVC Controller and Application Controller
Posted April 6th, 2008 by Adam
The Model-View-Controller design pattern provides a very useful separation between parts of an application. Unfortunately some other patterns have emerged that add confusion to what the parts of MVC really are.
The most striking example of this is the Application Controller1. A lot of web application frameworks use this pattern and often—if not always—AppController is the only type of controller available and this leads beginners to believe that this “controller” is in fact the C in MVC. (Ruby on) Rails is an example where this has happened.
AppController and the MVC Controller (hereafter only called Controller) are quite different beasts. Here’s a rundown of the two:
The Controller handles user input and communicates directly with both the Model and the View. (The View only displays information). It may be tightly coupled with the View, but not necessarily.
AppController Implements the Command pattern2. It takes a user request (in web frameworks this is typically an URL) and from the information retrieves a command object which it executes. Again, adding Rails to the conversation, it can be noted that Rails translates this into a method being called on a subclass to AppController. For instance, a GuestBook object might have methods such as create, read, update, delete. Additional data is passed either as an argument to the method, or available somewhere inside the instance.
So you can think of the AppController as a intermediary mapping between a request (on web, read: URL) and a controller. As it turns out, the mapping between Controller and URL scheme is one to one most of the time, meaning an AppController that is separated from the Controller would only produce glue code (AppController recieves an request on method A and immediately forwards to method A on the Controller). So the decision to combine the objects inside Rails is probably wise.
I started out using a web framework (yes, Rails) and got hopelessly confused as soon as someone started talking about MVC outside of the web. What eventually taught me MVC was reading Patterns of Enterprise Application Architecture3 and writing a simple drawing application (in Java + Swing) using several views for the same document, and a bunch of other details that I won’t bore you with.
Martin Fowler also adresses the differences in PoEAA, he does a good job in expressing that the two patterns are different, but in my opinion he doesn’t do as well in describing how they are different.
Other controller patterns to look out for are basically any ones not refered to as just “Controller”. Front Controller and Cocoa’s ArrayController and TreeController are a few examples. Suffixing a class name with Controller does not mean you are using MVC! Another point of confusion is that Cocoa programs have the opposite of our first problem as a convention. The main Controller is often named AppController!
-
Martin Fowler - Patterns of Enterprise Application Architecture - p. 379, Application Controller, http://www.amazon.com/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1207437024&sr=8-1 ↩
-
Gang of Four - Command Pattern, http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_3?ie=UTF8&s=books&qid=1207436939&sr=8-3 ↩
-
http://www.amazon.com/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1207437024&sr=8-1 ↩
Hi Adam,
Very nice to read your article.
I still have confusion about the role of Controller in MVC that I would like to ask you.
My work now is about a GUI for network simulations. Briefly I have to show up on the screen network topology (graph of graphical nodes and links) and then the communication activities on it (sending packets from nodes to nodes, etc).
Because of a GUI, MVC pattern seems to me a very natural choice, so I did choose it as a core pattern of my application. The graphics language is Qt. To apply MVC:
+ I have built up data structures which represent underlying information of networks and map them as Model in MVC.
+ I have built up graphics items (inherited from Qt based classes) which visually represent the associated network data objects on the screen, and consider them as View in MVC. One model can have more than one views, and one view is associated with one model.
+ Finally, I have one class that I consider as Controller. Most of the time, its responsibilities are to receive visualization requests from the network simulator to show up network activities graphically on the screen. During the time, it makes changes in the Model and sometimes control the View. It also intepretes commands from users and pass them to the simulator (stop, start, pause, etc).
Briefly, I just use only one Controller to control all views and models. It seems against the principle in MVC that each view has one controller and vice versa. So I do not know what I have done so far could be considered as MVC or not. Or in another word, the Controller in this case is really the C in MVC or not? If not, then what can I call it?
I would much appreciate if you could give me any opinion about it. Thank you.
VT
Hi VT,
I'm glad you liked the article!
From your description it sounds like you managed to construct a good solution to your problem.
As for your question: Blindly following the description of a design pattern might get you into a mess, a lot of them can be understood on some intuitive level rather than by strict rules. As an example; is an object Observable even if it's addSubscriber method is called, say, add()? Probably. Is it Observable if only one object may subscribe at a time? Perhaps. Add that it's like any word in a dictionary, it may change its meaning as time passes. On one hand you shouldn't use design pattern just to use design patterns, but on the other hand design patterns are general solutions to common problems, so it's likely that they can help.
Looking at the original MVC document, Controllers are described as follows:
A controller is the link between a user and the system. It provides the user with input by
arranging for relevant views to present themselves in appropriate places on the screen. It
provides means for user output by presenting the user with menus or other means of giving
commands and data. The controller receives such user output, translates it into the appropriate
messages and pass these messages on to one or more of the views.
So the description clearly shows that several views can share a controller. Depending on how your views work I think that it might make sense to use some kind of "sub controller" for small groups (or single) views.
Are you happy with how the codebase looks? Is there little code duplication? Is there not too much glue code to piece the controllers together?
Would combining several controllers make it better? If not, then it might be best to stick with what you've got, it's not a bad solution just because you haven't implemented MVC the way the "author" describes it.
I find that the intuitive notion of MVC is something like "Model takes care of domain and business logic, The View displays data and the Controller receives input." I don't see how anyone could argue that you break MVC by using a lot of controllers.
As for the name, is it so common that it deserves a name? If not you might get by with a description of it in the terms of MVC. Something along the line "Like MVC, but controllers only handle one view, for these reasons: ...". If you need something like a short and descriptive class name for your code I'm not completely sure what I'd call it (I'm usually terrible at these naming games), but I will probably think about it whether I want to or not :-). If I manage to come up with something I'll write another comment. Is SubController specific enough? Perhaps it could be used as a temporary name, until something better comes along.
I hope this helps, feel free to post another comment if you have more questions!
Hi Adam,
I am very thankful to you for your answer. It makes me feel more confident with my solution (that's what I have tried to find but failed with google :)
About the name, here what I mean is more than how to identify it by a string of characters :). I would like to know whether there is any other available pattern that fits to my solution more than MVC. Because I have found that there are a number of evolutions of MVC during its timeline, for example, MVP for "Model-View-Presenter" or some kind of "Supervising Controller", etc, what have made me so confused.
Again thank you very much for your answer.
Wish you a good day!
VT
VT: I thought about it for a while, but I don't recall hearing about any variation resembling your setup. But just because I don't know doesn't mean there isn't one :-). I hope you manage to find one, or manage to come up with a good name yourself!
Post new comment