Improving MVC usage

Question

I'm busy building an MVC application in PHP using Kohana MVC framework, and it works very well. But there are some small annoyances which I'd like to address.

A lot of logic is repeated across actions in controllers and controllers themselves. I've been thinking about it, and I thought it would be smart to define an object which contains this shared logic, so it doesn't get repeated.

Then I heard about view-models in some podcasts and on Preventing mission creep in your Views, or, ignorance is bliss. So view-models are what I was looking for.

But now comes the question, what do you put in the view-models. My idea was that I let the view-model gather all the information the corresponding view needs. This has the advantage that every controller/action just needs to pass the input data to the view-model, and then pass it to the view.

Is this a smart idea? On behalve of testing, it would be smart to pass the model to the viewmodel so it's possible to mock it. But I'm not really using models. In stead, I let the controllers access the database via Doctrine ORM. Translating every query to a seperate method seemed a little awkward, but maybe I'm missing something.

From what i've heard about view-models, they're just plain DTO's. But what's the advantage of that in a dynamically weakly typed language?

Maybe I'm on the wrong track entirely and should be doing it different. What are your thoughts about this?

Edit:

Most of the logic I'm talking about is gathering the right information and passing it to the right views.

An example:

I have a customer controller. These have two actions: add and edit. For these two actions, I use the same view. In both actions, the same variables for the view are assigned. In the add action, when the form is not valid, the input variables are passed to the view again. In the edit action, the existing values are passed trough. This is a big duplication which I'd like to address.

Answer 1

Repeated logic is an indication that some refactoring is needed, you don't say what that loic is so we can't be sure where you refactor it to, but Do Not Repeat Yourself is a useful principle. So original idea is good. I wonder whether your direct interaction from Controller to DB (ie. the lack of a Model) is part of the reason for duplication?

View Models are more than DTOs. They contain (or point to) Business Data and also have the relevent interpretation logic. In the "mission creep" article you reference you see the idea. The View itself wants to know whether to display a link. That decision is based on various pieces of business data. You pull together that logic in a simple showLink() method. Then the view can focus on presentation and the viewModel can focus on the interpretaion. And, also important, the actual Business Data itself has no idea about the presentation.

Answer 2

Addressing your concern in the earlier paragraph about repeated code in controllers... With Kohana, I generally put common controller code in a base controller and inherit all my controllers from that.

For example, in one project I am using a modified version of Template_Controller to make a reference to the Auth module available to every page as $this->auth.

abstract class Template_Controller extends Controller {

 /* @var Auth_Core reference to authorization class */
 protected $auth;

 public function __construct()
 {
  parent::__construct();
  [snip]
  $this->auth = new Auth();
 }
[...]
}

Now all my controllers start out like this:

class Help_Controller extends Template_Controller {

All controllers thus have access to $this->auth inside any function. Agree to keep biz logic out of views, that's the whole idea.