The Controller in an MVC pattern

[kyberfabrikken]

As far as I've seen, having the controller pass the Model to the View is the common accepted definition of the pattern ...

The only way to have a full view/controller separation, is by letting the view select the model. The controller selects the view, but it shouldn't pass any model to the view.
Of course, you may chose to have less separated view/controller layers. In many cases, this makes sense, since the further separation would just add bureaucracy. Calling it MVC is slightly misleading though.

[33degrees]

Why pass the entire model object on to the view? The view should only need exactly the data it requires to render the view, is that not correct? The controller seems like the logical place to handle this.

Because it's not the controller's responsibility to know exactly what information to display, beyond what it can infer from the user's input. By extracting the data in the controller, you increase the coupling between the controller and the view, which makes your application less flexible. The more information about the view the controller has, the more chances there are that changes to the view will mean changes to the controller, and supporting multiple views with the same controller becomes more complicated.

[33degrees]

The only way to have a full view/controller separation, is by letting the view select the model. The controller selects the view, but it shouldn't pass any model to the view.

That is valid opinion, but I disagree. A view is a visualization of the state of a model; having it decide which model to display increases it's responsibilities outside the realm of presentation, into analysis of the user's request, which is the controller's job. This is important because, just as a controller can share multiple views, multiple controllers can share the same view. I use generic views like this often; for example, an xml export view that can display the content of any model.

Of course, you may chose to have less separated view/controller layers. In many cases, this makes sense, since the further separation would just add bureaucracy. Calling it MVC is slightly misleading though.

I don't think it's misleading, because it's a commonly accepted definition of MVC as it applies to web applications.

[champ]

This is a bit ambiguous, but in his code examples he passes the model object itself to the view. As far as I've seen, having the controller pass the Model to the View is the common accepted definition of the pattern

Let's say I had the following class:

class Users
{
    function find_all()
    {
        // return database result set.
    }
}

Your controller implementation would pass the Users object directly to the view:

class Controller
{
    function execute()
    {
        $users = new Users;
        $view->set('users', $users);
    }
}

instead of passing the data:

class Controller
{
    function execute()
    {
        $users = new Users;
        $view->set('users', $users->find_all());
    }
}

For the first approach, the view would be responsible for calling the find_all() method?


correction: had the code blocks in the wrong order. fixed.

[33degrees]

For the first approach, the view would be responsible for calling the find_all() method?

No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view. Initially, I had my finder methods be static methods on the model class, but this eventually lead to a bunch of problems.

I wouldn't have the view call find_all, because find_all can take parameters (like page number, or sort order), and it's the controller that handles that stuff.

[champ]

No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view.

Just for clarification, you mean something like:

class User
{
    public $id;
    public $email;
    public $username;
}

class Users
{
    function find_by_id($id)
    {
        // Query the DB for a user record by id.
        // Convert the result set row into a User object.
        // Return User object, or false if nothing found.
    }
}

class Controller
{
    function execute($id)
    {
        $users = new Users;
        $user  = $users->find_by_id($id);
        $view->set('user', $user);
    }
}

If that's the case, I have a feeling there may not actually be a disagreement in what you're suggesting. I think there's been confusion regarding how we're individually defining what is or isn't a Model.

[33degrees]

Just for clarification, you mean something like:

Yes, that's what I mean. Confusion is an unfortunate reality when discussing topics like this

[McGruff]

Users is definitely a domain object.

I'd strongly disagree with calling something MVC unless there is a genuine separation between controller and view. I don't like nuts in my ice cream.

Views are free to read from domain objects and a view object should make the finder call.

[shea]

That nuts and ice-cream analogy is silly due to the line - "Guaranteed nut free. Only ten per cent nuts".

No one is saying they have guaranteed a 100% separation of view and controller. It's a design pattern - there are multiple ways to skin a cat depending on the problem at hand.

[pakmannen]

Wow, this is complicated stuff. I assumed that $user = new User() was the model object, but okey.. 33degrees, would this be "correct" then?

class DisplayUser extends Controller
{
    function __construct()
    {
        $this->user = new User();
        $this->view = new View('displayuser');
        $this->view->user = $this->user->DisplayUser($_GET['id'])
        $this->view->Output();
    }
} 

The controller is responsible for executing the model methods? For instance, when someone logs in, the Controller executes the login method before letting the View render the page?

[Jasper Bekkers]

The controller is responsible for executing the model methods?

The controller is responsible for invoking modifications on the model (methods called set/append/save/store et cetera), the view is responsible for reading data from the model (usually getters or properties).

[kyberfabrikken]

This is important because, just as a controller can share multiple views, multiple controllers can share the same view. I use generic views like this often; for example, an xml export view that can display the content of any model.

You can reuse view code in other ways than by letting the controller be middleman. Instead of having one component render the entire view, you can cut it into smaller blocks (helpers), which are model-agnostic. You can then have multiple views share the same helpers, but still leave it to each individual view to select the model. A common form of helper is a template. It's an extra layer of complexity, but that's exactly what MVC is about. You trade simplicity for decoupling.

[pakmannen]

The constructor is responsible for invoking modifications on the model (methods called set/append/save/store et cetera), the view is responsible for reading data from the model (usually getters or properties).

So you would not agree with either:

class Controller
{
    function execute($id)
    {
        $users = new Users;
        $user  = $users->find_by_id($id);
        $view->set('user', $user);
    }
} 

nor

class DisplayUser extends Controller
{
    function __construct()
    {
        $this->user = new User();
        $this->view = new View('displayuser');
        $this->view->user = $this->user->DisplayUser($_GET['id'])
        $this->view->Output();
    }
} 

Since they are both controllers that "gets" data from the model?

[McGruff]

No one is saying they have guaranteed a 100% separation of view and controller. It's a design pattern - there are multiple ways to skin a cat depending on the problem at hand.

If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.

In practice MVC has come to mean whatever the individual says it means, and thus has become completely meaningless.The only way not to go mad is to treat it like a comedy sketch.

[pakmannen]

So people disagree with Martin Fowler on this:

The controller should determine which view should display the result and pass on the model information to it.

The controller should NOT pass any model information to the View? It should only select the View?

[Jasper Bekkers]

So you would not agree with either:
Since they are both controllers that "gets" data from the model?

I would pass the $id to the view instead and let the view decide on what information it needs from the model.

class Controller{
   public function execute($id){
      if($this->request->isPost()){
         $user = $this->locator->get('User');
         $user->save(sanatize($this->request->form()));
      }
      $view = new View();
      $view->set('user_id', sanitize($id));
      $view->render();
   }
}

class View{
   public function render(){
      $user = $this->locator->get('User');
      $userDataForDisplay = $user->find_user_by_id($this->get('user_id'));
   }
} 

So people disagree with Martin Fowler on this:

That depends on the definition of model information he is using. If $id could be considered model data I'm agreeing with him, if it means passing the actual model, or data fetched from the model I'm disagreeing.

[pakmannen]

I would pass the $id to the view instead and let the view decide on what information it needs from the model.

class Controller{
   public function execute($id){
      if($this->request->isPost()){
         $user = $this->locator->get('User');
         $user->save(sanatize($this->request->form()));
      }
      $view = new View();
      $view->set('user_id', sanitize($id));
      $view->render();
   }
}

class View{
   public function render(){
      $user = $this->locator->get('User');
      $userDataForDisplay = $user->find_user_by_id($this->get('user_id'));
   }
} 

Yes, that makes sense.

That depends on the definition of model information he is using. If $id could be considered model data I'm agreeing with him, if it means passing the actual model, or data fetched from the model I'm disagreeing.

Someone said he passes the actual model on to the view. But I see how you think here.

Let's see, how about this:

Model selection actually appears in both the Controller and the View, but for different reasons. The Controller only writes data to the Model (based on user input), while the View reads data. The View knows by itself which Model(s) to call; the Controller does not pass this information on to the View.

Basically:
1. The Controller checks user input.
2. If anything is to be written to the Model, the Controller does this.
3. The Controller creates a View (and sends along GET information such as $id)
4. The View reads from the Model(s) it needs (when needed using the GET information)
5. The View outputs the page.

[Jasper Bekkers]

Someone said he passes the actual model on to the view. But I see how you think here.

That's how I used to do it, but it created more headaches than manageable when I wanted to add another model to the view.

Basically:
1. The Controller checks user input.
2. If anything is to be written to the Model, the Controller does this.
3. The Controller creates a View (and sends along GET information such as $id)
4. The View reads from the Model(s) it needs (when needed using the GET information)
5. The View outputs the page.

6. The model can optionally inform both the controller and the view through an observer, but that's a rare case for web-applications.

[pakmannen]

I put together a quick picture. Something like this then?

[33degrees]

If you announce that you're going to have a separate view and controller - MVC - and then don't bother to keep them apart you might as well claim to be a vegetarian and then insist that vegetarians are free to implement vegetarianism with as many degrees of meat-eating as they like.

Sorry, but your analogies make no sense, although I do think I understand your position. The problem is simply that our definition of View differs. As far as I can tell, for you the View contains two parts; the first part finds the data to display, the second part actually does the displaying. In my view (pardon the pun), only the second part is actually a view, the first simply a specialized controller which is used in the context of displaying the page. So, you define what is a view based the context of the user request (editing data vs displaying it), I define view as simply the part that displays model information.

There is a very strict separation of what is View and what is Controller in my case, I just don't draw the line at the same place.

[ahundiak]

I put together a quick picture. Something like this then?

The line from the view back to the controller should read something like "Rendered output". The "User Input" (or Request) comes from the front controller to the controller usually via some sort of dispatcher.

[ahundiak]

I would pass the $id to the view instead and let the view decide on what information it needs from the model.

I go one step further and turn MVC into MVCT where T stands for templates. The view class receives the $id and queries the model for user information. If the user is to be edited, the view might also query the model different information such as possible user roles and permissions. Whatever the html form might need.

The view collects this information and passes it on to a template class for rendering. For different output formats, different templates would be chosen but still using the same information.

[Czaries]

No, but it's because in your example, I don't consider your Users object to be a model. In my code my models represent a single database row, and I use finder objects to retrieve the models I need. So, the controller uses a finder object to get one or more models, and then passes the single model, or an array of models, to the view. Initially, I had my finder methods be static methods on the model class, but this eventually lead to a bunch of problems.

I wouldn't have the view call find_all, because find_all can take parameters (like page number, or sort order), and it's the controller that handles that stuff.

Wow, this is complicated stuff. I assumed that $user = new User() was the model object, but okey.. 33degrees, would this be "correct" then?
...

You have been a bit misguided. The "model" is really only an ambiguous term that describes the data access layer. 33degrees is apparently using the RowDataGateway or ActiveRecord pattern to implement this, but it's certainly not the only way to do it. The term "model" has no real specific definition other than it must be the "data access" layer, so your implementation may very well be a valid "model".

[pakmannen]

I go one step further and turn MVC into MVCT where T stands for templates. The view class receives the $id and queries the model for user information. If the user is to be edited, the view might also query the model different information such as possible user roles and permissions. Whatever the html form might need.

The view collects this information and passes it on to a template class for rendering. For different output formats, different templates would be chosen but still using the same information.

I'm also trying to create a template based solution. At the moment my "flow" sort of looks like this: FrontController -> "Command" -> View -> Template

It feels like one of them is redundant. Should I really have to create three files (command, view, template) for each "new" page? I'm curious how you solved this. Is it possible to integrate the "Commands" into the FrontController or something?

[McGruff]

The "model" is really only an ambiguous term that describes the data access layer.

The model is another name for the domain layer not the data access layer.