Общее программирование: как реализовать логику модели в MVC?

Question

В настоящее время я пытаюсь выяснить, как правильно реализовать принцип MVC.Возьмем для примера простой блог.У меня есть база данных, которая содержит две таблицы: блоги и комментарии.Таблица блогов состоит из таких полей, как заголовок, контент, дата и т. Д. Комментарии содержат имя, дату, контент и тому подобное.

Давайте начнем с более простых элементов.У меня есть пара просмотров.Например:

• Запись / редактирование элемента блога
• Отображение элемента блога
• Отображение сводной страницы (например, недавние блоги, популярные темы и т. Д.)
• и т. Д.

Контроллеры мне также вполне понятны:

• Контроллер администратора (переносит элементы блога в представления записи / редактирования или отправляет их обратно)
• Контроллер блога (переносит элементы блога в представления блога, такие как сводная страница или страница, на которой отображается только один. Это также возвращает комментарии)
• Контроллер комментариев (переносит данные из создания / удаления комментариявзгляды)

Но потом идут модели.Я действительно не знаю, как мне это реализовать.Страница быстрого запуска Zend Framework рекомендует довольно небольшую модель, содержащую только частные свойства, а также методы получения и установки для конкретного элемента.Они рекомендуют делать логику базы данных в Mapper.

Но вот мой вопрос.Допустим, я хочу получить самые последние записи в блоге.Как бы вы это реализовали?Где бы вы написали функцию fetchRecentItems ()?В маппере?Похоже, что это должно содержать только основные заявления CRUD.В другой модели, как BlogService?В контроллере?

Может кто-нибудь помочь мне здесь?Я хотел бы увидеть пример с коротким псевдокодом.

(Я попытался обобщить свои знания, чтобы сделать мой мыслительный процесс немного более понятным. Если я что-то понял неправильно, пожалуйста, исправьте меня. Спасибо!)

Answer 1

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

class Yourapp_Service_Blog
{
    protected $_mapper;

    public function setMapper($mapper)
    {
        $this->_mapper = $mapper; 

        return $this;
    }

    public function getMapper()
    {
        return $this->_mapper;
    }

    public function fetchRecentItems($items)
    {
        $select = $this->getMapper()->getDbTable()->select();
        $select->order('createdAt DESC')
               ->limit($numItems);

        return $this->getMapper()->fetchAll($select);
    }
}

так что тогда в вашем контроллере:

class BlogController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $service = new Yourapp_Service_Blog();
        $service->setMapper(new Yourapp_Model_GuestbookMapper());

        $this->view->posts = $service->fetchRecentItems(6);
    }
}

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

Здесь нет «правильного» ответа, хотя эти паттерны существуют как решения общих проблем программирования. Используйте столько, сколько считаете нужным для вашего приложения.

Answer 2

Полностью согласен с идеей сервисного уровня, хотя это действительно зависит от того, что у вас работает.

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

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

Я слышу, откуда ты, потому что я был там не так давно. Долгое время я был озадачен тем, как реализовать модель с Zend Framework. Я искал соглашение или кого-то, чтобы описать, как это должно быть сделано.

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

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

Мой совет для Google по поводу "Zend Framework Service Layer" и прочитайте как можно больше об этом - я думаю, что это может вас заинтересовать. Чаще всего вы возвращаетесь к переполнению стека, но обычно есть ссылки на хорошие посты и статьи в блогах.

Удачи.

Answer 3

Не существует только одного способа разработки приложения MVC. В целом, существует множество различных подходов к тому, какие контроллеры, представления и модели должны быть или должны быть.

Думаю, хорошая идея - посмотреть, как это сделали другие.

Посмотрите на CakePHP: Модели / Просмотров / Контроллеры

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