CODEWITHSUNDEEP
phpmodel-view-controller
spirytus
spirytus

Reputation: 10946

General on mvc... should controller pass data to view or view should grab it directly from model?

I’m trying to learn and fully understand mvc pattern and learn php at the same time. I decided to built basic mvc framework that I could use on various projects later on. Having read lots of posts in here regarding mvc and coupling between models/views/controllers I’m a bit lost.. At the moment my understanding is that in web application controllers deal with coming request from browser and, if necessary, calls methods on model classes telling models to change its state. Then controller instantiate appropriate view class that will be responsible for displaying interface. Here's the bit I don’t understand...

  1. Now should controller pass appropriate model object to view and view should pull out all the data from model when needed?

  2. Or controller should grab data from model and pass it to view, possibly wrapping it all into single wrapper object that view will access and grab data from there?

  3. Or view should simply instantiate appropriate model when needed and pull out data directly from model object?

From what I read here

http://www.phpwact.org/pattern/model_view_controller

I’d lean towards the 3rd option where controller doesn’t pass anything to view and view instantiates model it needs. This is because:

  1. view and controller should have same access to model

  2. controller shouldn’t act simply as mediator in between view and model.

Is there really one correct way to do it or it rather depends on project? Also what approach would you recommend to someone who has decent understanding of OOP but is relatively new to php and not too clear on mvc architecture. Or maybe I should go with whatever seems right to me and learn from my mistakes (would like to avoid this one though ;)?

Now, please let me know if my question is not clear will try to better explain then.. Also I read lots of posts on stackoverflow and numerous articles on different sites, but still would appreciate help so thanks in advance for all answers.

Upvotes: 11

Views: 5705

Answers (8)

Carl Barrett
Carl Barrett

Reputation: 229

The reason why so many developers today can't get the knock of MVC is because the abbreviation of MVC was incorrectly stated from day one when it arrived into software development, but the concept is correct back then and also today. Since I am from the old school, let me explain it for you; when you are creating an object you first create a Model so the customer can View it, once it is approved you will have full Control on how the object is going to be made. That's how it is to this day in product manufacturing.

In today’s web application development such term should be VCM. Why! You View what's on the web browser, and then you click a button for action, that is known as the Controller. The controller alerts the Model, which is the instruction or logic to produce a result (that is your script). The result is then sent back to the user for viewing. In software engineering, you can refer to it as CMV; because the user won't able to view anything until the apps is compiled and installed. So we will need a Controlling device (PC); the OS as the Model and a monitor to View the results. If you can understand those concepts, MVC should start to look much more appetizing. I hope this concept will help someone to understand MVC.

Upvotes: 1

Vladislav Rastrusny
Vladislav Rastrusny

Reputation: 29965

I think this is just a generic argue about what is better "push" or "pull" model. There is no "absolutely" best solution.

Upvotes: 3

Imagist
Imagist

Reputation: 18514

I tend toward having the controller act as an intermediary between the model and the view, but generally this is literally a single line of code that connects the three together. If your model, view, and controller are properly decoupled it should make very little difference which you use.

Upvotes: 0

troelskn
troelskn

Reputation: 117427

Personally, I've always been a proponent of #3. The view shouldn't care about the controller. The view shouldn't have any dependency on the controller for that matter. It should do what it's supposed to do, show a view of the model.

The basic flow of control should be thus: The controller receives a request from a browser. It makes any updates to the model, that is relevant, and then selects a view. The control is then passed to the view, which gets data from the model and renders it.

As an extension, user input can be consider part of the model, and both the controller and the view may read from it. The key point to take away is that Controller and View should have no dependency on each other. That's why the pattern is called MVC.

Now, personally, I find MVC a bit too tedious, and so I usually conflate Controller and View more than this. But then that isn't really MVC.

Upvotes: 8

Matthew Scharley
Matthew Scharley

Reputation: 132234

Personally, I've always been a proponent of #2. The view shouldn't care about the model. The view shouldn't have any processing at all for that matter. It should do what it's supposed to do, format data.

The basic flow of control should be thus: The controller recieves a request from a browser. It processes the request, decides what data is needed, and retrieves it from the model/s. It then passes the data into the view which format the data and displays it.

As an extension, user input is processed inside the controller, and saved into a model if needed, then feedback is fed into a view, etc. The key point to take away is that processing happens inside the controller.

Upvotes: 15

elviejo79
elviejo79

Reputation: 4600

This is a very interesting question. From my experience most implementations in php assign a model variable to the view:

$this->view->my_property = $modelObj->property

This is common practice. The common reasoning for this is that if you send the object then you can call methods that modify the object from the view.

//in the controller file
$this->view->myObject = $modelObj;

//in the view file, you could call an object modifying method
$this->myObject->delete();

And modifying the model from the view is considered bad practice. Some people thing that they don't want their designers being able to call model modifying methods from the view.

That being said. I don't agree with the common practice and tend to assign the whole object to the view and display it from there. And just discipline my self to not make operations there.

And a third option is to assign the whole object to the view. but some how in the objects disable methods when they are called from the view.

Upvotes: 5

Tordek
Tordek

Reputation: 10872

Web MVC and Desktop MVC are two very different beasts.

In Web MVC, a link in a View calls a method on a Controller, which updates a Model, and then redirects to an appropiate View, which opens up a Model and shows what it needs.

In a Desktop MVC, option 3 is wrong because both the view and the model should use the same reference. In Web, there's no choice.

Option number 2 is not MVC. It's MVP, wherein the Presenter is a mediator.

A Controller has Write-Access to a Model; a View has only Read access.

Upvotes: 6

DevDevDev
DevDevDev

Reputation: 5177

I had a very similar question earlier. I find helpful to think of it as follows:

MVC
Model -- Data store, alerts Views of changes
View -- Displays model, provides hooks for user interaction
Controller -- Handles user input

You would use MVC more often in non-web apps, where lots of classes are interacting with eachother simultaneous.

In a web application MVC means MVT (Model-View-Template)

Model -- Strictly a data store, typically an ORM solution
View -- Handles web requests, provides for user input/output
Template -- Actually displays content (HTML, Javascript, etc.)

So in a web application the presentation is handled in the Template, the logic behind the application is handled in the View (or classes called by the view), and the model is responsible for holding data.

Upvotes: 1

Related Questions