2 Answers
2

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 i need from model layer. Controller only changes state of model layer and current view by applying user input the them.

In the simplest implementations of other MVC-inspired design patterns (MVVM and MVP) the controller-like structures (ViewModel and Presenter - respectively) provide view with the data from 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.

Hi, could you clarify that the controller changes the state of the model layer? I was always taught that a request goes through a router to a controller. The controller then uses the layers in the model to manipulate the data etc, then finally provides the data to the view. As I've come to realised, what I had learnt was limited and even incorrect in some cases. Also, how would you suggest that I inject a factory instead of passing the database adapter?
–
bearJan 1 '13 at 21:04

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.