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

Question

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

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

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

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

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

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

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

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

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

Это правильный подход?

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

Answer 1

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

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

Answer 2

Я не работал с KohanaPHP, но это похоже на фреймворк, вдохновленный рельсами. В мире рельсов, как правило, рекомендуется использовать узкие контроллеры и толстые модели.

некоторый фон можно найти в этой старой статье Джеймиса Бака 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

Answer 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, где yУ вас есть несколько сайтов, использующих один и тот же API, но с другой логикой.

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

Answer 4

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

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

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

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

** Опечатки исправлены.