Я «делаю это неправильно» в Кохана 3? - PullRequest
Новая
       11

Я «делаю это неправильно» в Кохана 3?

0 голосов
/ 04 марта 2010

Когда у меня есть контроллер, например У меня часто есть статья 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());
        }

    }

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

Ответы [ 2 ]

3 голосов
/ 04 марта 2010

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

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

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

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

1 голос
/ 04 марта 2010

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

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

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

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

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

...