Контроллер против модели - требуется объяснение

Я нахожусь в начале моего "Learn MVC". В принципе, у меня нет больших проблем с объектно-ориентированным программированием, однако есть один технический аспект, который нуждается в уточнении. Похоже, что моя теория недостаточно хороша.

В настоящее время я использую структуру KohanaPHP, версию 3.

Пример ситуации: У меня есть веб-сайт, на котором пользователь может отправить статью.

Итак, у меня есть следующая структура:

classes/
    /controllers/
        article.php
    /models/
        articles.php

Пока все хорошо. У меня нет проблем с моделями, которые расширяют Kohana_Model, но я не уверен, использую ли я правильные модели, использующие ORM.

В основном при использовании моделей, расширяющих Kohana_Model, я положу все логические операции в модель. Должен ли я делать то же самое для моделей, использующих ORM? Во многих примерах по сети я видел контроллеры, которые выполняли логические операции с пользовательскими вводами/данными из базы данных, что, по моему мнению, неверно.

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

В принципе, все операции с пользовательским вводом/данными (выберите из db, insert into db, validation), которые я ввел в модели. Это то, как я понимаю шаблон дизайна MVC. Модели должны заботиться обо всех "механических" операциях, а контроллер - всего лишь "мост" между моделями/видами, а это "передний" двигатель.

Правильно ли он подходит?

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

Ответ 1

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

Надеюсь, я ясно дал понять, дайте мне знать, если это не ясно для вас.

Ответ 2

Я не работал с KohanaPHP, но он выглядит как "основанный на рельсах" Framework. В мире рельсов обычно считается лучшей практикой иметь тощие контроллеры и толстые модели.

некоторый фон можно найти в этой старой статье jamis buck http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model или в этом вопросе о cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

Ответ 3

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

Возьмем этот пример:

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id = false)
    {
        if(!$user_id)
        {
             $user_id = get_guest_id();
        }
        //Insert
    }
}

Кажется законной логикой в моделях, но отныне ваша заявка должна позволять гостям публиковать статьи или ее недостатки, и вам нужно отредактировать модели, которые затем заполнят ваши другие приложения/области вашего сайта

Возьмите этот сценарий:

У вас есть 2 сайта

ComputerArticles.com
CookingArticles.com

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

Ваши методы модели должны выглядеть так:

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id)
    {
        $this->compile("articles",array($title,$text,$user_id))->insert();
    }
}

И внутри ваших контроллеров вы должны поместить всю свою логику, поскольку логика будет зависеть от домена.

Подумайте о своих моделях как API, где у вас несколько сайтов, использующих один и тот же API. Но по разной логике.

Надеюсь, что это поможет.

Ответ 4

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

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

Теперь ваш вопрос. Где идет бизнес-логика? Ну, это обработчик действий. Или это абстрагируется где-то люди любят звонить - бизнес-уровень. Но в любом случае он срабатывает от самих обработчиков действий.

Итак, технически бизнес-логика является частью действий, которые сами являются частью Модели. Это имеет смысл, если вы так думаете: контроллер управляет взаимодействием с пользователем и представляет представления на основе модели (действия + бизнес).

** Исправлено опечатки.