Php – In MVC, can/should basic data retrieval from the Model be done in the View

design-patternsmvcPHP

Given the concept of 'skinny controllers, fat models' and the general acceptance that Views can directly call on Models when requiring data for output, should one consider handling the 'get and display' parts of requests within the Views and not the Controller? For example (attempted to keep code fairly generic):

Controller

<?php

class Invoice extends Base_Controller {

    /**
     * Get all the invoices for this month
     */

    public function current_month() {

        // as there's no user input let's keep the controller very skinny,
        // DON'T get data from the Model here, just load the view

        $this->load->view('invoice/current_month');

    }

}

View

<?php

// directly retrieve current month invoices here

$invoices = $this->invoice_model->get_current_month();

// get some other display-only data, e.g. a list of users for a separate list somewhere on the page

$users = $this->user_model->get_users();

?>

<h1>This month's invoices</h1>

<ul>
<?php foreach ($invoices as $invoice) { ?>

<li><?php echo $invoice['ref']; ?></li>

<?php } ?>
</ul>

To me, this makes at least some sense in the cases where a request is essentially just a View. Why should the Controller have to collect and pass on the data to the View when it can just retrieve it itself? This leaves the Controller open for purely 'Application level' processing (e.g. handling GET/POST requests, managing access rights and permissions etc.) as well as keeping the Models reusable and all the other good stuff.

If this example was extended to allow a user to filter the results, the Controller would just handle the POST from the form and pass the filters to the View, which would then request the data again, this time with the filters.

Is this a valid approach to developing an MVC application? Or am I overlooking an important part of the role a Controller should play?

Best Answer

Yes, it can technically be done. No, it shouldn't be done. And yes, you're missing a bit of what the controller is there for.

The controller is there to decouple the View from the Model. The decoupling is beneficial because you should look at the View as almost throw-away code. As your UI technology changes, you want to minimize the rework required in generating a new View. The controller enables that decoupling and provides a place for your code that will live through UI technologies.

It works in reverse as well if you need to add to or change out your Model. All of the upstream changes will be contained within the Controller and your Views will be left alone.

The other risk is that while the View is very simple now, you have less guarantee that it will remain so simple throughout its life. By calling the Model directly from the (very simple) View, you've opened the door a bit to allow additional bad practice to creep in later when the very simple View needs to become not-so-very simple. A future developer will be tempted to make more Model calls from the not-so-very simple View instead of refactoring the code and interacting with a Controller.

Related Topic