What goes into the “Controller” in “MVC”?

Question

I think I understand the basic concepts of MVC - the Model contains the data and behaviour of the application, the View is responsible for displaying it to the user and the Controller deals with user input. What I'm uncertain about is exactly what goes in the Controller.

Lets say for example I have a fairly simple application (I'm specifically thinking Java, but I suppose the same principles apply elsewhere). I organise my code into 3 packages called app.model, app.view and app.controller.

Within the app.model package, I have a few classes that reflect the actual behaviour of the application. These extends Observable and use setChanged() and notifyObservers() to trigger the views to update when appropriate.

The app.view package has a class (or several classes for different types of display) that uses javax.swing components to handle the display. Some of these components need to feed back into the Model. If I understand correctly, the View shouldn't have anything to do with the feedback - that should be dealt with by the Controller.

So what do I actually put in the Controller? Do I put the public void actionPerformed(ActionEvent e) in the View with just a call to a method in the Controller? If so, should any validation etc be done in the Controller? If so, how do I feedback error messages back to the View - should that go through the Model again, or should the Controller just send it straight back to View?

If the validation is done in the View, what do I put in the Controller?

Sorry for the long question, I just wanted to document my understanding of the process and hopefully someone can clarify this issue for me!

Answer 1

Practically speaking, I've never found the controller concept to be a particularly useful one. I use strict model/view separation in my code but there's no clearly-defined controller. It seems to be an unnecessary abstraction.

Personally, full-blown MVC seems like the factory design pattern in that it easily leads to confusing and over-complicated design. Don't be an architecture astronaut.

Answer 2

Controller is really part of the View. Its job is to figure out which service(s) are needed to fulfill the request, unmarshal values from the View into objects that the service interface requires, determine the next View, and marshal the response back into a form that the next View can use. It also handles any exceptions that are thrown and renders them into Views that users can understand.

The service layer is the thing that knows the use cases, units of work, and model objects. The controller will be different for each type of view - you won't have the same controller for desktop, browser-based, Flex, or mobile UIs. So I say it's really part of the UI.

Service-oriented: that's where the work is done.

Answer 3

As I understand it, the Controller translates from user-interface actions to application-level actions. For instance, in a video game the Controller might translate "moved the mouse so many pixels" into "wants to look in such and such a direction. In a CRUD app, the translation might be "clicked on such and such a button" to "print this thing", but the concept is the same.

Answer 4

The MVC pattern merely wants you to separate the presentation (= view) from the buisiness logic (= model). The controller part is there only to cause confusion.

Answer 5

You are essentially right about what you put in the controller. It is the only way the Model should interact with the View. The actionperformed can be placed in the View, but the actual functionality can be placed in another class which would act as the Controller. If you're going to do this, I recommend looking into the Command pattern, which is a way of abstracting all of the commands that have the same receiver. Sorry for the digression.

Anyway, a proper MVC implementation will have the following interactions only: Model -> View View -> Controller Controller -> View

The only place where there may be another interaction is if you use an observer to update the View, then the View will need to ask the Controller for the information it needs.

Answer 6

We do it thusly, using Controllers mainly to handle and react to user-driven input/actions (and _Logic for everything else, except view, data and obvious _Model stuff):

(1) (response, reaction - what the webapp "does" in response to user) Blog_Controller

->main()

->handleSubmit_AddNewCustomer()

->verifyUser_HasProperAuth()

(2) ("business" logic, what and how the webapp "thinks") Blog_Logic

->sanityCheck_AddNewCustomer()

->handleUsernameChange()

->sendEmail_NotifyRequestedUpdate()

(3) (views, portals, how the webapp "appears") Blog_View

->genWelcome()

->genForm_AddNewBlogEntry()

->genPage_DataEntryForm()

(4) (data object only, acquired in _construct() of each Blog* class, used to keep all webapp/inmemory data together as one object) Blog_Meta

(5) (basic data layer, reads/writes to DBs) Blog_Model

->saveDataToMemcache()

->saveDataToMongo()

->saveDataToSql()

->loadData()

Sometimes we get a little confused on where to put a method, in the C or the L. But the Model is rock solid, crystal clear, and since all in-memory data resides in the _Meta, it's a no-brainer there, too. Our biggest leap forward was adopting the _Meta use, by the way, as this cleared out all the crud from the various _C, _L and _Model objects, made it all mentally easy to manage, plus, in one swoop, it gave us what's being called "Dependency Injection", or a way to pass around an entire environment along with all data (whose bonus is easy creation of "test" environment).