What is the job of controller in MVC?

Question

I am trying to learn the MVC architecture. But I am not able to understand why you need a controller. See the below code for my model and view.

model.php connects to the database and retrieves the post. view.php will just display the post.

model.php

<?php
  $db = mysql_connect("somehostname", "someuser", constant("somepassword"));
  mysql_select_db("somedatabase", $db);

  $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'");
  $row = mysql_fetch_array($result);

  $post = $row["post"];

  mysql_close($db);
?>

view.php

<?php
  require "model.php";
  echo $post;
?>

I set my browser location to http://whateverhost/view.php?id=5

This loads post with the id 5. I did not require a controller here. So I am confused why do you need a controller?

Note: Please explain with reference to the above example. I am not a programming geek and learning things like CakePHP, etc. is overwhelming for me.

Edit: It would be great if you can add controller.php to the above code. That would help me in understanding the role of a controller and how it communicates with model and views.

Answer 1

You don't need a controller because your example is trivial. An example from a real case scenario:

Suppose you have a CAD application. The CAD application is arranged as MVC. You have:

• a view which is responsible for drawing the current model, and provide clickable entities.
• a model, which keeps the current data to be represented
• a controller, whose role is to get the events from the view, and convert them into proper entities so to modify the model.

For example, the user clicks on a square and deletes it. The controller will receive the event from the view, creates an object representing a command (via the Command pattern), add it into a queue for undo capability and executes the command. The command will then modify the model, but the responsibility of translating view events into the complex machinery that modifies the model is under the responsibility of the controller.

Of course you could say, why isn't the view creating Command objects then? well, nobody forbids you that, but you would end up having presentation logic mingled with operational logic. This goes against good design, although for the most trivial cases, you could live with this design. For example, if your CAD application allows you to display the list of objects both as a 3D representation and as a list of entities, and you could delete from both, you clearly see that either the two views both implement the same logic to handle the command pattern (bad design), or they just channel the same message to a common controller (good design, the MVC).

Answer 2

model.php is in this case you controller.

The roles of model, view and controller are not easy to distinguish if you don't have a good MVC framework (plain PHP isn't a good one).

The Model is your data structure wich is made persistent in a DB. In terms of code if mainly consists of a data structure as a class.

The View just displays the data. Mainly html with some scripting tags.

The Controller controls what happens. For instance, a user edits a post. The data is received by the controller, maybe modified a little bit (added timestamp, users ip) and sent to the model in order to store it. The controller then decides wich view to display next and what data to fetch for the new view.

Just a small example.

Answer 3

IMHO in MVC the controller has two main purposes:

1. The testability of the GUI logic or anything the GUI triggers. In most cases you can write unit tests for the controller relatively easy, it's much harder for GUIs like PHP or Windows Forms for example. The former depends on a browser, the later depends on Windows Messages, both doesn't make your life easier when you write unit tests. It's nearly the same with any other presentation layer technology.
2. The interchangability of the presentation layer or (in some cases) the controller. There are scenarios where you can use the same controller in two GUIs (a "light" form for a special case and a "rich" form for another case) or the other way round (not that often).

In a scenario with much more functionality than in your sample you will see the advantages. But you should decide for or against MVC and use the same approach in every form of you application, don't mix it. I would prefer MVC, you do almost always need controller logic.