Я “делаю это неправильно” в Kohana 3?

Question

Когда у меня есть контроллер, напримерстатья, в которой я часто встречаюсь с action_view() это обрабатывает большую часть кода.

Иногда он может достигать 80-100 строк в длину.

Мой контроллер обычно обрабатывает все это:

• привязка переменных шаблона
• настройка сеансов (там, где это уместно)
• отправка электронных писем
• формы для проверки подлинности

Я мог видеть фрагменты, которые я мог бы создать другим частным методом в контроллере, не обязательно для повторного использования, но и для разделения проблем.

Однако тогда это выглядит странно (для меня), имея методы, которые могут быть вызваны через маршрут, и методы, которые являются только внутренними.

Также некоторые вещи говорят мне: "Я должен быть в модели, а не в контроллере".Однако я тоже не уверен, правильно ли это.

В конце концов, у меня есть несколько жирный метод контроллера, который выглядит довольно процедурно.

Должен ли у меня на самом деле быть список в верхней части моего action_* методы, а затем разделить остальную часть моего кода на более мелкие модули?

У меня есть пример ниже...это типичный материал контроллера, или сеансы и т.д. Должны быть в модели?

public function action_pdf($type, $id) {

        // Get PDF file from db and send headers to it
        $id = (int) $id;

        $pdfFile = $this->model->getPdf($id, $type);

        if ($pdfFile) {
           $this->request->redirect($pdfFile);
        } else {
           $this->session->set('pdfMissing', true);
           $this->request->redirect(Route::get('properties')->uri());
        }

    }

Итак, мой вопрос в том, делаю ли я это неправильно?

Answer 1

Ваши модели есть для инкапселирования бизнес-логики и обычно для абстрактных хранилищ данных вдали от остальной части архитектуры (контроллеры, представления).

Это означает, что любые доступ к базе данных (например, запросы SQL), и такие должны быть в идеале, в идеале содержатся в ваших моделях. Ваш контроллер получит свои данные из ваших моделей (это включает в себя ORM, которая выставляет себя через модели) без самого необходимости получать доступ к базе данных.

Что касается отправки электронной почты, я думаю, это зависит от ситуации. Например, когда пользователь подписывает, я называю метод модели, чтобы вставить свои данные в базу данных. Этот метод затем запускает электронное письмо, которое будет отправлено им. Таким образом, я делаю электронную почту, отправив явную часть бизнес-логики для регистрации (и это то, что я хочу в этом случае), поэтому независимо от того, кто вызывает метод регистрации в модели, система не забудет отправить электронную почту.

Когда дело доходит до проверки формы, я пытаюсь указать большую часть моих правил проверки в классах модели ORM. Это так, чтобы независимо от того, кто манипулирует модель, модель всегда имеет некоторое присущее понимание того, как подтвердить свои собственные данные. И вы заметите, что объект модели ORM уже предоставляет метод проверки его данных. Любая дополнительная проверка / обратные вызовы Модель не по своей природе не нужно знать о том, чтобы отслеживать отслеживать, можно сделать за пределами кода модели.

Answer 2

IANAPHPD (я не разработчик PHP), но перспектива разработчика общего языка программирования (Java / C #) может быть полезной.На мой взгляд, одним из преимуществ MVC является содействие повторному использованию кода, когда у вас есть основная бизнес-логика и инфраструктура, которые должны быть представлены несколькими пользовательскими интерфейсами.Например, система управления заказами, имеющая веб-интерфейс, а также интерфейс рабочего стола.В данном случае этой основной логикой является Модель.Каждый из трех интерфейсов имеет свои собственные представления и контроллеры.В C # тривиально структурировать ваш код таким образом, чтобы основная логика находилась в наборе пакетов / сборок, на которые ссылаются из проекта пользовательского интерфейса рабочего стола, а также проекта веб-приложения.

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

Это несколько неестественный способ мышления о PHP-коде, поскольку PHP так тесно привязан к веб-платформе (насколько я знаю).Несмотря на это, этот способ мышления все еще остается в силе (разделение проблем и не повторяйтесь), и его все еще можно применять: вторичным "пользовательским интерфейсом", который мог бы поддерживать PHP, был бы API веб-сервиса.Если функция должна быть доступна как для веб-сайта, так и для API веб-службы, то она должна быть представлена в Модели.

Вам может быть интересно, а может и нет, но в целом такой способ мышления прекрасно интегрируется с доменно-ориентированным дизайном.

Примечание:Хотя все пользовательские интерфейсы, поддерживаемые PHP, основаны на веб-интерфейсе, я бы все же остерегался включать в модель проблемы, связанные с вебом (все, что связано с сеансами браузера, файлами cookie, отслеживанием посещений и т.д.), В первую очередь потому, что эти проблемы ориентированы на презентацию, а не на бизнес, и, во-вторых, потому, что это затрудняет перенос системы по частям на другой язык / платформу по какой-либо причине позже.