MVC, what is best practice to fill my presentation model?

Question

I have taken a look into this:

http://r.je/mvc-in-php.html

According to it, i would have the following basic Code:

//Instance of a Model
$model = new Model();

//Controller and View get the Model
$controller = new Controller($model);
$view = new View($model);

//Controller change/work with the Model
$controller->doSomeAction();

//Display the final Model
$view->display();

I already have implemented my Application in Domain Driven Design. But now I am stuck at the presenetation layer, which I want to implement in classic MVC.

At the moment, my controller would make a instance of the model and the view (Which seems to be wrong with the above code):

//Get Model
$model = $myRepository->findById(42);

//Do Some stuff
$model->foo = 'foo';
$model->bar = 'bar';

//View
$view = new MyView($model)
$view->render();

The Id 42 is comming from the Request. But how i can transfer it according to the first real MVC code? I mean, i have no static Model, the model is dynamic by Request.

Something like this feels wrong, because the Model know about the Request:

class MyPresentationModel extends PresentationModel {
    public $foo;
    public $bar;

    public function __construct($request) {
        //init myRepo...
        $obj = $myRepo->findById($request->get(42));
        $this->foo = $obj->getFoo();
        $this->bar= $obj->getBar();
    }
}

So what is the best practise to fill my presentation model?

Answer 1

Full disclosure: I am the author of that article and got directed here because this URL appeared in as a referer in analytics.... hence the late reply!

This is a separation of concerns issue. What should know about the request object? The answer to that is easy if you ask "What does the request object contain?" Well, the "42" is a choice by the user to see some information about the record with that ID, as such it's essentially a user action "I want to see record 42".

Because of this, the controller should have access to the request object:

class Controller {
    private $request, $model;

    public function ___construct(Model $model, Request $request) {
        $this->request = $request;
        $this->model = $model;
    }

    public function viewAction() {
        $this->model->load($this->request->id);
    }
}

The model can be Dynamic and based on the request, but it's the job of the router, not the job of the controller to select the model. The reason for this is flexibility, you could have a model that loaded the record from a database or a model with the same API that loaded the record from a CSV file or a web service, all three of these models are interchangable, if you construct the model in the controller it means you need a controller for each model option which is messy due to repeated code.

The same is true of views. You could have a view which displayed the output as HTML and another that displayed the record in JSON, another as an RSS feed and another as a PDF.. however they'd all use the same controller and model.

Linking this all together shows the flexibility of MVC. With the classes:

HTMLView PDFView RSSView

Controller

DatabaseModel CSVModel WebServiceModel

You have an incredible number of possible options:

• Getting data from a database and displaying it as HTML
• Getting data from a database and displaying it as PDF
• Getting data from a database and displaying it as RSS
• Getting data from a CSV and displaying it as HTML
• Getting data from a CSV and displaying it as PDF
• Getting data from a CSV and displaying it as RSS
• Getting data from a Web Service and displaying it as HTML
• Getting data from a Web Service and displaying it as PDF
• Getting data from a Web Service and displaying it as RSS

All the while using the same reusable set of classes. This is the beauty of MVC and why the components are separate entities.