What, specifically, belongs in a Model, a View, an

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 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" logic~~Edit: 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 like include $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?

回答1:

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?

回答2:

Essentially you have everything in the right place.

In your example you define a Question class - which would be known as a ViewModel, simply a container for all the data that is to be used in the View/ retrieved from the View.

In some cases I have seen the ViewModel overlooked and the Model is passed to the View - this confused me when I was first looking at tutorials, and I don't like omitting the ViewModel, I think it confuses things.