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

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

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

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

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

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

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

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

Изменить:

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

Пример:

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


person Ikke    schedule 23.12.2009    source источник


Ответы (2)


Повторяющаяся логика указывает на то, что необходим некоторый рефакторинг, вы не говорите, что это за логика, поэтому мы не можем быть уверены, куда именно вы ее рефакторите, но принцип «Не повторяйте себя» — полезный принцип. Так что оригинальная идея хороша. Интересно, является ли ваше прямое взаимодействие от контроллера к БД (т.е. отсутствие модели) частью причины дублирования?

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

person djna    schedule 23.12.2009
comment
извините, я не понимаю дублирования между добавлением и редактированием, мне не кажется, что код точно такой же - person djna; 23.12.2009

Отвечая на ваше беспокойство в предыдущем абзаце о повторяющемся коде в контроллерах... С 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 внутри любой функции. Согласитесь, чтобы бизнес-логика не попадала в представления, вот и вся идея.

person Barnabas Kendall    schedule 23.12.2009
comment
У меня уже есть такая установка. У меня есть контроллер приложения, который расширяет контроллер шаблона. И каждый второй контроллер расширяет контроллер приложения. Так много общей логики уже сосредоточено в одном месте. - person Ikke; 23.12.2009