bear
bear

Reputation: 11605

MVC, what goes where

At the moment, I've got a fat controller and a thinner model layer.

My controller looks something like this.

namespace controller;
class home
{


    public $template = 'home';

    protected $database;

    public function __construct(\Zend\Db\Adapter\Adapter $database){
        $this->database = $database;

    }

    /**
     * Returns the home page
     */
    public function indexView(){


        $userService = new UserService($this->database);
        $view = new ViewModel($this->template);
        $view->assign('pageTitle', 'Home');
        $view->assign('lead', "Welcome ".$userService->getFirstName());
        $view->assign('h1', 'Home');


    }
}

My model would consist of data manipulation, data gathering etc.

The viewModel class this calls, the view, is basically a container class which includes the header, footer and the actual template used inside.

In terms of MVC, I now understand that the Model and View are aware of each other.

Am I going about this the right way?

Upvotes: 0

Views: 759

Answers (2)

tereško
tereško

Reputation: 58444

Short answer: no, you are not doing it the right way, or even slightly correct-ish way.

The MVC design pattern is all about separation of concerns. You separate the model layer from presentation layer - to split the domain business logic from how it is demonstrated.

In presentation layer you split the components that are responsible for user interaction (controllers) from those that govern the UI creation (views).

The model layer too is subject to some separation, though that usually is not covered in "mvc for beginners by beginners" blog posts. I wrote a short description in an earlier post. But if you want to actually understand how to implement model layer, you will have to read Folwer's PoEAA.

In classical MVC (which you cannot use for web) and Model2 MVC patterns the view request all the data that it needs from the model layer. The controller only changes the state of the model layer and the current view by applying user input to them.

In the simplest implementations of other MVC-inspired design patterns (MVVM and MVP) the controller-like structures (ViewModel and Presenter - respectively) provide the view with the data from the model layer. That also means that having a viewmodel inside a controller makes no sense whatsoever. You can read more about MVP pattern in this publication.

P.S. also, why are you injecting DB connection in the controller when all you will do with it is to pass it along? That code fragment is violating LoD. If you need to acquire structures from model layer inside a controller, you should be injecting a factory instead.

Upvotes: 0

Aram Kocharyan
Aram Kocharyan

Reputation: 20421

The MVC pattern has many variations, including MVP (Model View Presenter) and everywhere you look these can be explained slightly differently.

One thing that is usually common is that the model should be entirely unaware of both the controller or the view. This allows interchanging the model as desired. There is nothing the model needs from either.

Instead, the observer pattern is employed whereby the model is the observable and the controller and/or view are the observers. When something in the model changes, it calls the update/notify method for its observers and notifies them it has changed.

One variation is the supervising controller which manages the view but doesn't interfere with events and such:

As the example shows, the essence of a good Supervising Controller is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved.

Finally, in terms of PHP check this helpful answer which points to using the CodeIgniter MVC. If you're looking at other web frameworks, the Yii Framework seems to have MVC covered quite well also.

Upvotes: 2

Related Questions