MVC: Model View Controller — does the View call th

问题:

I've been reading about MVC design for a while now and it seems officially the View calls objects and methods in the Model, builds and outputs a view.

I think this is mainly wrong.

The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display. Only crude and rudiementary PHP variables/simple if statements should appear inside the View.

If the View gets the information it needs to display from the Model, surely there will be a lot of PHP inside the View -- completely violating the point of seperating presentation logic.

回答1:

As with all things programming we need to be pragmatic. A view should only contain presentation logic. That logic can be very simple or can be quite complex. As long as that logic only handles what is displayed on the screen, printed on the report, etc.

The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display.

What is this information you are passing? Possibly a subset of a model. You could create a new class containing only the information the view should know about or just pass along the model and make sure you only access appropriate data. Anyway, the view should be free to query this passed in model to be able to display a view.

The point of controversy is if you from the view should be able to update the model directly, bypassing the controller. This is where the pragmatic side comes in. I think there are cases that can warrant updating the model directly. Especially if you can use data bindings. The you can assign a text box to a property of the model and let the update automagically happen. If there are a lot of simple property setting this approach can save a bunch of code in the controller. MVC is not a set of rules set in stone. It's guidelines that when used correctly can produce better code but if used too rigorously can lead to pain and suffering.

Be pragmatic!

回答2:

There isn't one absolute and correct way to do MVC. Variations are possible.

For example, instead of having the View actively querying the Model, the Controller can notify the view of any changes in the Model, using some sort of notification mechanism. In that case, the View is just listening for updates, which are then being presented.

回答3:

It's probably not what one would call "pure" MVC, but IMHO it's not a huge deal as long as the view PHP code doesn't mutate the model. The most important rule of MVC is that the model doesn't know about the view. Having the view not know about the model is less important.

The main downside to using the model directly is that the view can't be reused with a different model. This is rarely a problem, because the view is almost always specific to one particular type of model object (or a list thereof).

回答4:

Would the following modifications to DisgruntledGoat's code snippet be considered too "complex"? Should objects be passed to the view?

<li><?=$item->description?></li>

Or maybe?

<li><?=$item->getDescription()?></li>

I've seen several examples where only arrays are used:-

<li><?=$item['description']?></li>

回答5:

MVC refers to layers, not components. So they are more abstract concepts, than a blueprints. Since it's not really possible to separate the layers entirely (Information has to flow between them), it's really a continuum where you have spaghetti on one extreme and bureaucratic type systems on the other. You probably want to find somewhere in between those two.

I generally don't spend too much effort on the controller-view separation. The separation between model and (controller-view) is much more important.

回答6:

MVC is not a law set in stone. Depending on where you read about it it can differ. Personally I don't allow the View to read directly from the Model.

Update This post has some good examples as well. The model is the engine of the car with start() like methods, the view is the color of the car with paint() or change() methods and the controller is the driver. I prefer to let the controller drive() the car and start() the engine instead of letting the wheels or the paint doing it.

:)

回答7:

I think you are absolutely correct - Views shouldn't call methods from the Models. Like others said, there are variations on MVC but the point it to separate logic from data from output.

So generally, you have a controller which is the start point for the application. In PHP, this would be your index.php file. At a minimum this file would process the input data (i.e. the query string or URL parameters). It's usually a good idea to add separate controllers for separate parts of the app.

Each controller then simply decides what data needs to be displayed, gets it from the model, and passes it to the view. In PHP, you would call various classes/methods that fetch data from the database, storing it in variables.

Then you simply include another PHP file containing mostly HTML, but with some PHP echoing variables. Loops are fine, too. If you have a list of things, you may want to do something like this:

<ul>
<?php foreach ($items as $item) : ?>
  <li><?=$item?></li>
<?php endforeach; ?>
</ul>