Можно ли выполнить какую-либо обработку на модели? [MVC]

Question

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

Случай, который поднял этот вопрос, - видео сайт. У меня есть класс Video (модель) и одна из вещей, которые мне нужно сделать, когда пользователь просматривает видео, мне нужно, чтобы его просмотр был зарегистрирован в базе данных. Я не уверен, нужно ли мне добавить запрос в контроллер или я могу добавить метод addView в классе Video.

Основной вопрос для меня заключается в том, какими методами я ограничен в моделях? Это может быть что-нибудь или это должны быть только методы доступа (a.k.a getValue / setValue)?

Answer 1

Ruby on Rails имеет девиз тощий контроллер, толстая модель . Это не относится только к Rails и должно применяться на любом фреймворке mvc.

Answer 2

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

Answer 3

Вот как бы я это сделал. Он должен быть действителен практически на любом языке.

Представление инициирует вызов метода для метода OnView () контроллера, а затем отображает все то, что контроллер ему плюет (контролируемым образом, конечно ... Я думаю, что ваше представление будет содержать видео компонент проигрывателя, так что вы получите какое-то видео с контроллера)

В вашем контроллере есть метод OnView (), который выполняет 3 вещи: создание экземпляра объекта Video (т.е. использует слой данных для получения объекта модели), вызов метода updateViewCount () для объекта Video и отображение видео (по-видимому, возвращая объект Video в View).

Объект Video model содержит данные, представляющие ваше видео, и все необходимые материалы для домашнего хозяйства, включая updateViewCount (). Основанием для этого является то, что видео имеет количество просмотров (агрегация). Если «количество просмотров» должно быть сложным объектом, а не просто целым числом, пусть будет так. Слой данных, который создает объекты Video из их примитивного представления на диске (база данных?), Также будет отвечать за загрузку и создание соответствующего объекта подсчета просмотров как часть создания видео.

Итак, это мои 0,02 доллара. Вы можете видеть, что я создал четвертую вещь (первые три - это Model, View и Controller) - слой данных. Мне не нравится, когда объекты Model загружаются и сохраняются сами, потому что тогда они должны знать о вашей базе данных. Мне не нравится, когда контроллеры выполняют загрузку и сохранение напрямую, потому что это приведет к дублированию кода между контроллерами. Таким образом, отдельный уровень данных, к которому должны иметь доступ только контроллеры.

В качестве заключительного замечания, вот как я смотрю на представления: все, что делает пользователь, и все, что видит пользователь, должно проходить через представление. Если на экране есть кнопка с надписью «play», она не должна напрямую вызывать метод контроллера (во многих языках это не опасно, но некоторые, например PHP, потенциально могут это разрешить). Теперь метод представления "play" просто развернется и вызовет соответствующий метод на контроллере (который в этом примере - OnView) и ничего не сделает, но этот уровень концептуально важен, даже если он не имеет функционального значения. Аналогично, в большинстве ситуаций я ожидаю, что ваше представление будет воспроизводить видеопоток, поэтому данные, возвращаемые контроллером представлению, будут потоком в том формате, который требуется представлению, который может не обязательно быть вашим точным объектом Model (и добавлением этот дополнительный слой развязки может быть целесообразным, даже если вы можете использовать объект Video напрямую). Это означает, что я мог бы на самом деле заставить мой метод OnView принимать параметр, указывающий, какой формат видео я хочу вернуть, или, возможно, создать отдельные методы просмотра на контроллере для каждого формата и т. Д.

Достаточно долго наматывается для тебя? : D Я ожидаю немного пламени от разработчиков Ruby, у которых, похоже, немного другое (хотя и не несовместимое) представление о MVC.

Answer 4

С MVC люди, кажется, пытаются приспособить четыре слоя к трем.

Парадигма MVC не правильно обращается к хранилищу данных. И это «четвертый слой». Модель имеет свою обработку; но так как он также обращается к данным, программисты также используют SQL. Неправильно. Создайте слой абстракции данных, который является единственным местом, где следует общаться с внутренним хранилищем. MVC должен быть DMVC.

Answer 5

Имейте в виду, существует множество вариаций MVC, и нет реального «правильного» способа сделать что-либо. В конечном счете, то, как вы разрабатываете свои занятия, зависит от личных предпочтений. Однако, так как вы попросили совета по дизайну, вот мои два цента:

Бизнес-логика принадлежит контроллеру. Держите его подальше от модели и вида.

Из многих вариаций шаблона MVC стиль пассивного просмотра представляется наиболее простым для тестирования. В пассивном виде ваши занятия оформлены следующим образом:

• Ваш контроллер "умный": он вносит изменения в базу данных, обновляет модель и синхронизирует представление с моделью. Помимо ссылки на модель и представление, контроллер должен содержать как можно меньше информации о состоянии возможно.

• Модель "глупая", то есть она содержит только состояние представления и не требует дополнительной бизнес-логики. Модели не должны содержать ссылку ни на представление, ни на контроллер.

• Представление «глупое», то есть оно копирует информацию только из модели в пользовательский интерфейс и вызывает обработчики событий, которые обрабатываются контроллером. Представление не должно содержать дополнительной бизнес-логики. Представления не должны содержать ссылку на контроллер или модель.

Если вы являетесь пуристом MVC, то для модели не имеет смысла обновлять себя или базу данных, поскольку эти обязанности принадлежат контроллеру, поэтому не будет целесообразно для создания addView метод к вашему видео классу.

Answer 6

Поскольку вы можете использовать любой код модели, какой захотите, с MVC (не ограничиваясь только LINQ), короткий ответ - да. Что следует сделать в модели, возможно, является лучшим вопросом. На мой вкус, я бы добавил свойство ViewCount (которое, вероятно, отображается на столбец в таблице Video, если только вы не отслеживаете пользователя, в этом случае оно будет в таблице UserVideo). Затем из контроллера вы можете увеличить значение этого свойства.