Улучшение использования MVC

Question

Я занят созданием приложения MVC на PHP с использованием инфраструктуры Kohana MVC, и оно работает очень хорошо. Но есть некоторые небольшие неприятности, на которые я хотел бы обратить внимание.

Много логики повторяется в действиях контроллеров и самих контроллеров. Я думал об этом, и я подумал, что было бы разумно определить объект, который содержит эту общую логику, чтобы он не повторялся.

Затем я услышал о моделях представления в некоторых подкастах и ​​на Предотвращение ползания миссии в ваших представлениях, или невежество - блаженство . Итак, модели для просмотра - это то, что я искал.

Но теперь встает вопрос, что вы вкладываете в view-модели. Моя идея состояла в том, чтобы я позволил модели представления собрать всю информацию, необходимую для соответствующего представления. Это имеет то преимущество, что каждому контроллеру / действию просто нужно передать входные данные в модель представления, а затем передать их в представление.

Это умная идея? В момент тестирования было бы разумно передать модель в модель представления, чтобы можно было поиздеваться над ней. Но я не пользуюсь моделями. Вместо этого я позволил контроллерам обращаться к базе данных через Doctrine ORM. Перевод каждого запроса в отдельный метод показался немного неловким, но, может быть, я чего-то упустил.

Из того, что я слышал о моделях представления, они просто DTO. Но в чем преимущество этого в динамически слабо типизированном языке?

Может быть, я полностью на неправильном пути и должен делать это по-другому. Что вы думаете об этом?

Edit:

Большая часть логики, о которой я говорю, - это сбор правильной информации и передача ее нужным представлениям.

Пример:

У меня есть контроллер клиента. У них есть два действия: добавить и изменить. Для этих двух действий я использую одно и то же представление. В обоих действиях назначены одни и те же переменные для представления. В действии добавления, когда форма недопустима, входные переменные снова передаются в представление. В действии редактирования существующие значения передаются через. Это большое дублирование, к которому я бы хотел обратиться.

Answer 1

Повторная логика является признаком того, что необходим некоторый рефакторинг, вы не говорите, что это за лойка, поэтому мы не можем быть уверены, куда вы его реорганизуете, но не повторяйте себя - это полезный принцип. Так что оригинальная идея хороша. Интересно, является ли ваше прямое взаимодействие между Контроллером и БД (т. Е. Отсутствие модели) одной из причин дублирования?

Модели просмотра - это больше, чем DTO. Они содержат (или указывают на) бизнес-данные, а также имеют подходящую логику интерпретации. В статье «Миссия ползучести», на которую вы ссылаетесь, вы видите идею. Само представление хочет знать, отображать ли ссылку. Это решение основано на различных бизнес-данных. Вы объединяете эту логику простым методом showLink () . Затем представление может сосредоточиться на представлении, а viewModel может сосредоточиться на интерпретации. И, что немаловажно, сами бизнес-данные не имеют представления о представлении.

Answer 2

Обращаясь к вашему беспокойству в предыдущем параграфе о повторяющемся коде в контроллерах ... С Kohana я обычно помещаю общий код контроллера в базовый контроллер и наследую все мои контроллеры от него.

Например, в одном проекте я использую модифицированную версию Template_Controller, чтобы сделать ссылку на модуль Auth доступной для каждой страницы как $ 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();
    }
[...]
}

Теперь все мои контроллеры запускаются так:

class Help_Controller extends Template_Controller {

Таким образом, все контроллеры имеют доступ к $ this-> auth внутри любой функции. Согласитесь не допускать логики бизнеса, вот и вся идея.