I’ve been learning about the Model-View-Controller paradigm (“MVC”), but I’m quite confused since some tutorials contradict other tutorials.
My current understanding of the process looks something like this:
Router / Dispatcher / Front Controller:
- Though not specifically referenced in the “MVC” name, the Router is still a very important part. It is here that requests are translated from raw URLs to a specific controller. For example, routing a request for http://www.StackUnderflow.com/question/123 to the “Question” Controller of the application.
Model:
-
This is where raw data is collected from some storage source, such as a database or XML file. The model serves as an abstraction layer, translating the Controller’s request for specific data into (for example) an SQL query, and translating the query results into a standard format like a data object.
-
For example, in the /browse/all scenario stated above:
- The “Question” Controller would ask the Model “Please give the data for question 123.”
- The Model would then translate that into “SELECT * FROM Questions WHERE Id = 123;” and punt it to the database
- The database would return a “Question” record to the Model.
- The Model would take the record, and translate it into a Question data object
- The Model then asks does the same thing “SELECT * FROM Answers WHERE QuestionID = 123;” and creates an array of Answer objects from the resultset, and adds that to the Question object’s answers member variable.
- The Model would return the Question object to the “Question” Controller.
Controller:
-
This is the real workhorse of the application. In addition to relaying messages back and forth to the Model and the View, the Controller is also responsible for things like Authorization
and application/”business” logicEdit: Per answer, business logic belongs in the Model. -
In the ongoing example, the Controller wold be responsible for:
- Ensuring the user is logged in.
- Determining the QuestionId from the URL.
- Determining which View to use.
- Sending HTTP codes and redirecting if needed.
- Asking the Model for data, and store needed data in member variables.
View:
- By and large, the View is the simplest part of the application. It mostly consists, in a basic application, of HTML templates. These templates would have placeholders to insert data into the template from the Controller’s member variables:
e.g.
<html>
<head>
<title>
<?php $question->getTitle() ?>
</title>
</head>
<body>
<h1> <?php $question->getQuestionText(); ?> </h1>
<h2> Answers: </h2>
<div class="answerList">
<?php formatAnswerList($question->getAnswers()); ?>
</div>
</body>
</html>
- The View would also contain methods to format data for delivery to the user. For example, the
formatAnswerList()method above would take an array of answers, taken from the Controller, and loop through them while calling something likeinclude $markupPath . "/formatAnswer.inc"which would be a small template of just an answer container.
Questions:
- Is this view of MVC fundamentally accurate?
- If not, please carefully explain which components are misplaced, where they should actually go, and how they should properly interact with the other components (if at all).
- How many classes are used to describe this? In my example there are four objects – one each for the three components of MVC and one that simply stores related data for transmission. Is this normal, or should some be combined. If so, which ones?
I think this description puts too much weight on the controller and not enough on the model. The model is ideally where the business logic resides. The controller is really just an interface for the user of the site, routing control where it needs to go. Take a look at a previous discussion on the topic:
Understanding MVC: Whats the concept of "Fat" on models, "Skinny" on controllers?