Geek Answers Handbook

How do MVC components fit together?

I have seen several examples of how MVC components integrate on the Internet.

The controller returns data from the Model and transfers it to the View

It 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 several 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 one is the “best” way to do things? If not, then what?

+4
source share
5 answers

The controller returns data from the Model and transfers it to the View

As you said, this is verbosity and confusion. But this is the most suitable solution with the MVC philosophy.

The controller passes the model to the view.

It seems really. However, for the presentation, it is necessary for him to have some kind of model method. Which is really not in the spirit of MVC. Your view should display only the data that is provided to it, not caring for the context.

The controller passes the view to the model

Forget about it. It's dirty here.

+8
source

The answer is obvious, given that the “model” is a central artifact (potentially used in all applications) and that the “view” may (or may not) be up to date with a particular model, but it (by definition) is “view” (potentially abstract) models and again, potentially suitable for use in applications. The "controller" controls the interaction and is the most application-specific element of the template, so it must know about the details of the model and presentation.

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

Option 3 is simply incorrect.

+1
source

The answer to the original question:

  • The controller returns data from the Model and transfers it to the View

MVC is actually very neat and clean. Remember that it addresses:

  • Code reuse (Models do not rely on controllers or views. Views are independent of controllers or models. Controllers are application specific.)

  • Separation of logic (for example, changing the authentication database from MySQL to LDAP requires changing 0 to the view. Changing the layout of the view requires changing the model to 0. Changing the structure of the database table requires 0 changes in the controller or view).

Now, if you want your forms to be automatically generated from the table structure, now the views are attached to the table (closely related). Changing the table requires a change in view (albeit potentially automatic). This may take less code, but the presentation no longer depends on the expectation point of code reuse.

Similarly, your views (in MVC) should be nothing more than templates. There should be no logic - just variables. All "logic", the so-called business rules, is in the controller. Models know how to get data and maintain normalization. Views know how to display data. The controller knows when to use data and what views apply data.

MVC is a rigorous three-tier architecture. For some applications, there is a two-tier architecture. For fast mashups and "getting shit", one related architecture may be appropriate (but you don't get style points).

Hope this helps.

+1
source

IMHO, option 2 ( The controller passes the model to the view ), in the best way supports proper isolation and separation of problems. If a view requires several models, the model should be a composite data type that contains each model necessary for the presentation. “Each model required for presentation” is usually different from your entity model in that it is smoothed and simplified for display, which is often called the ViewModel.

Option 1 ( The controller extracts data from the Model and passes it to the view ) is very similar to option 2, but option 2 is preferable, because the controller has less logic. In MVC, the maximum possible logic should be in the model, leaving your controllers and views as simple as possible.

0
source

I tend to agree with the second. MVC on the Internet cannot be implemented as it can in applications with a large number of states. Most web MVC implementations, you put your logic in your controllers and use the model to access raw data. I think the more correct way is your logic in your model. There is an almost implied 4th level in that raw data is accessed within the model, but the model is also responsible for what the data means and updates the view.

the wikipedia article explains this pretty well.

0
source

More articles:


All Articles