How do MVC components fit together?

Question

I've seen a number of examples of ways MVC components fit together on the web.

---

The Controller retrives data from the Model and passes it to the View

This seems a bit verbose and messy.

$model = new Model;
$view = new View;
$view->set('foo', $model->getFoo());
$view->display();

The Controller passes the Model to the View

What if the View needs data from multiple Models?

$model = new Model;
$view = new View($model);
$view->display(); //View takes what is needed from the Model

The Controller passes the View to the Model

$view = new View;
$model = new Model($view);
$view->display(); //Model has told the View what is needed

---

Which of these is the "best" way to go about things? If none, what is?

Answer 1

The Controller retrives data from the Model and passes it to the View

As you said it's verbose and messy. But that's the most appropriate solution with the philosophy of MVC.

The Controller passes the Model to the View

Seems valid too. However it'll require for the view to ask for some model method. Which is not really in the spirit of MVC. Your view should only render the datas that are provided to it, without caring about the context.

The Controller passes the View to the Model

Forget that one. Here it is messy.

Answer 2

IMHO, option 2 (the Controller passes the model to the view) best maintains the proper decoupling and separation of concerns. If the view needs multiple models, the model passed in should be a composite data type that contains each model needed by the view. "Each model needed by the view" is usually different from your entity model in that it is flattened and streamlined for display, often called a ViewModel.

Option 1 (the Controller retrives data from the Model and passes it to the View) is quite similar to option 2, but I contend option 2 is preferable because it places less logic in the controller. In MVC, as much logic as possible should be in the model, leaving your controllers and views as simple as possible.

Answer 3

I tend to agree with the second one. MVC on the web can't really be implemented as it can in more stateful applications. Most web MVC implementations have you put your logic in your controllers and use the model for raw data access. I think the more correct way is to put your logic in your model. There is almost an implied 4th layer in that raw data access is done within the model, however the model is also responsible for giving that data meaning and updating the view.

The wikipedia article explains it pretty good.

Answer 4

The answer is self evident if you consider that the 'model' is the central artifact (potentially used across applications), and that a 'view' may (or may not) be aware of the specific model but it is (by definition) a 'view' of a (potentially abstract) model and again, potentially usable across applications. The 'controller' is managing interactions and is the most application specific element of the pattern, so it definitively needs to know about model and view details.

If the view is specific to a given model, you can use option 2. If the view is for an abstract model (and you can use it to display info from a set of models), you use option 1.

Option 3 is simply wrong.

Answer 5

The answer to the original question is:

1. The Controller retrives data from the Model and passes it to the View

MVC is actually very neat and clean. Remember what it is addressing:

1. Code reuse (Models do not rely on controllers or views. Views do not rely on controllers or models. Controllers are app specific.)

2. Separation of Logic (For instance changing an authentication backend from MySQL to LDAP require 0 change to a view. Changing a view's layout requires 0 change to model. Changing the database table structure requires 0 change to the controller or view).

Now IF you want your forms to be automatically generated from a table structure - the views are now tied to the table (tightly coupled). A change in the table require a change in the view (albeit potentially automatically). This may take less code - but the view is no longer dependable from a code-reuse stand point.

Similarly your views (in MVC) should be nothing more than templates. There should be no logic - just variables. All the "logic", aka business rules, reside in the controller. The models know how to get data and keep it normalized. The views know how to display data. The controller knows when to use the data and which views to apply the data to.

MVC is a strict 3-tier architecture. A two tiered architecture is valid for some applications. For quick mashups and "getting crap done" a one tied architecture can be appropriate (but you don't get style points).

Hope this helps.