Почему я должен использовать шаблон MVC?

74

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

Итак, почему я должен использовать MVC? Что я получу, используя MVC, просто отделяя интерфейс от логики бэкенда? (Большинство «преимуществ», которые я вижу в этом шаблоне, получаются только путем отделения интерфейса от реализации и не объясняют цель наличия отдельного «контроллера»)

Билли ОНил
источник
9
MVC - это просто реализация разделения проблем . Подойдет любая реализация. Неиспользование «Разделений проблем» ведет к Большому грязевому
шару
1
@Raynos: Возможно. Но это не то, где происходит "шумиха".
Билли ONEAL
3
Обман подчиняется кривой обмана . Не позволяйте этому влиять на вас слишком сильно. С моей точки зрения, MVC является надежной архитектурой для SoC и проста в реализации. Я не могу придумать надежной альтернативы.
Рэйнос
большинство существующих структур пользовательского интерфейса тесно связывают V и C, и когда вы переключаетесь на другое, вам нужно переписать и представление, и контроллер (интерфейс от M к тому, что видит пользователь)
трещотка урод
Но разделение интересов - это свойство развития ОО. Вам не нужно использовать шаблон MVW для реализации правильного кода разделения проблем?
Бастьен Вандамм

Ответы:

50

Хех. Мартин Фаулер согласен с вашей путаницей в отношении MVC:

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

Однако он продолжает давать одно из более убедительных объяснений того, что мотивирует MVC:

В основе MVC лежит то, что я называю отдельной презентацией. Идея, стоящая за разделенной презентацией, состоит в том, чтобы сделать четкое разделение между объектами домена, которые моделируют наше восприятие реального мира, и объектами презентации, которые являются элементами графического интерфейса, которые мы видим на экране. Доменные объекты должны быть полностью автономными и работать без ссылки на презентацию, они также должны поддерживать несколько презентаций, возможно, одновременно.

Вы можете прочитать всю статью Фаулера здесь .

Gnawme
источник
19

Я чувствую, что это во многом зависит от проблемы, которую вы решаете. Я вижу разделение следующим образом:

Модель - как мы представляем данные? Например, как мне перейти от моих объектов к постоянному хранилищу, например, к БД -> как сохранить мой объект «Пользователь» в базе данных?

Контроллер - что я делаю? Это действие, которое происходит, и что на концептуальном уровне необходимо выполнить. Например, какие этапы мне нужно пройти, чтобы выставить счет пользователю? NB это может повлиять на любое количество объектов, но ничего не знает о том, как они сохраняются в БД.

Просмотр - как мне отрендерить результат?

Проблема, которую я чувствую, вы видите в том, что многие веб-приложения представляют собой прославленный CRUD-интерфейс (Create-Retrieve-Update-Delete) для БД. то есть контроллеру говорят «добавить пользователя», а затем он просто говорит модели «добавить пользователя». Ничего не получено.

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

Унк
источник
1
«в проектах, где выполняемые вами действия не относятся непосредственно к изменениям модели» Что вы подразумеваете под «моделью» здесь? База данных? Потому что все, с кем я говорил, говорят, что такие действия все еще принадлежат модели, а не контроллерам. (например, что контроллеры должны иметь дело только с HTTP-компонентом ...)
Billy ONeal
Что считается HTTP-материалом? Я бы включил следующее в контроллер: демонтирование параметров HTTP-запроса, проверка параметров для здравого смысла, определение того, что необходимо сделать, посещение соответствующих объектов модели (для чтения, записи или обоих), получение окончательного результата на основе ответов модели , передавая это на вид. Глупым примером того, для чего будет использоваться только контроллер, может быть веб-служба, генерирующая случайное число - в этом случае нет «модели», на которую можно смотреть (по крайней мере, на мой взгляд ...)
Unk
Это все модельные проблемы. Даже «решить, что нужно сделать» («фронт-контроллер») - это модель.
Билли ONEAL
2
Не говоря уже о контроллерах, которые полезны для того, чтобы не связывать ваши модели с вашими взглядами. А также позволяет вам подключать множество видов ко многим моделям через один контроллер.
Рэйнос
1
@Billy: если вы позволите представлению «связываться» с моделью - кроме запроса его значений - вы получите представления, которые больше похожи на контроллеры. Я думаю больше с точки зрения воплощения Model-GUI-Mediator MVC. Контроллер является посредником между моделью (поведение и данные домена) и графическим интерфейсом (представление модели на экране). Представление просто передает взаимодействия на контроллер (пользователь нажал ...). Контроллер решает, что (если есть) нужно вызвать в модели. Преимущества: ...
Марьян Венема
8

Ты не должен.

Позвольте мне перефразировать это. Вы должны использовать архитектуру, которая отделяет логику от ваших представлений. При необходимости следует использовать архитектуру, в которой используется контроллер (например, MVC), если требуется логика, которая не обязательно вписывается в модель (например, например, фрагменты URL для анализа обхода дерева).

Исходя из CI и Yii, я думал, что иметь выделенный контроллер было действительно крутой идеей. Однако при разработке приложений с надлежащими интерфейсами RESTful потребность в контроллере для обработки логики, не зависящей от модели, кажется, уменьшается. Таким образом, при переходе на Django, а затем на Pyramid (ни один из которых не полностью соответствует архитектуре MVC), я обнаружил, что контроллер на самом деле не был обязательным компонентом для приложений, которые я создавал. Обратите внимание, что обе платформы имеют функции контроллера, такие как диспетчеризация URL в Pyramid, но это конфигурация, а не среда выполнения (например, CController в Yii).

В конце концов, что действительно важно, так это отделение взгляда от логики. Это не только очищает вещи с точки зрения реализации, но также позволяет инженерам FE / BE работать параллельно (при работе в командной среде).

(Примечание: я не занимаюсь разработкой веб-приложений профессионально, поэтому, возможно, мне чего-то не хватает)

Демиан Брехт
источник
Я полностью согласен, хороший ответ. Контроллер не всегда необходим, он просто представляет собой стратегию взаимодействия представления с моделью.
Сокол
@Falcon: видите, это мое замешательство. Я видел, как несколько человек говорили, что представление вообще не должно разговаривать с контроллером; что он должен говорить только с моделью ...
Билли ONEAL
1
Если вы используете реальную реализацию MVC, представление не взаимодействует с контроллером (или моделью в этом отношении). Контроллер устанавливает состояние модели, подготавливает данные для представления и передает их в представление.
Демиан Брехт
@Demian: я слышал обратное (что контроллеры не должны делать ничего эффективно). Часто. Это моя самая большая проблема с этим шаблоном; кажется, никто не согласен с тем, что это такое.
Билли ONEAL
3
Да, я часто слышал, что если в комнате будет 10 программистов, вы получите 9 разных определений того, что такое MVC. Действительно, главное - это разделение интересов. То, что еще происходит, кажется религиозным спором.
Демиан Брехт
1

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

Относительно того, почему отдельный контроллер, причина может зависеть от того, о какой версии контроллера вы говорите.

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

Для других версий ИМХО сложнее показать конкретную выгоду. Я думаю, что это в основном проблема разделения интересов - отделить чисто визуальные проблемы GUI от логики, которая применяется к GUI, но не является частью бизнес-модели (например, переводить обновления из модели, в которую должны быть видны виджеты). Но на практике эти два класса, вероятно, будут настолько тесно связаны (даже если они взаимодействуют через интерфейсы), так что трудно слишком расстраиваться, объединяя их в просто представление, и просто следить за тем, как функциональность может быть более пригодной для повторного использования. если бы они были разделены.

PSR
источник
0

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

АЕК
источник
2
Это ничем не отличается от простого определения уровня пользовательского интерфейса и функционального уровня. Вы не объяснили, почему бит контроллера необходим.
Билли ONEAL
-3

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

ikartik90
источник
-3

Я думаю, что MVC используется просто модным словом теоретиками, которые являются менеджерами. Тем не менее, сказав, что текущая итерация сети с HTML5 преобладает, адаптивный дизайн и пытается создать единую линию программирования баз данных, которая будет работать в Интернете и на iPhone, подпадает под общие идеи MVC. Технология веб-интерфейса буквально движется со скоростью света прямо сейчас с Jquery, новыми итерациями управления CSS, тогда как серверная часть вещей движется со скоростью улитки.

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

В этом отношении, я полагаю, что в текущем реальном мире MVVM - действительно лучший «шаблон» или как вы хотите его называть, чем контроллер, потому что контроллер всегда должен возвращаться к модели, чтобы изменить представление, и это медленно. , В шаблоне MVVM ViewModel может немедленно обновить представление. Кроме того, модель MVVM поддерживает принципы дизайна RESTful IMHO.

Майкл Барбер
источник
это просто ваше мнение, или вы можете как-то это подтвердить?
комнат
3
(не понизил) Хорошо, это было модным словом, продолжающимся 40+ лет, если это так.
Билли ОНил
2
Я бы посоветовал вам провести дополнительное исследование происхождения паттерна MVC и дополнительных паттернов, которые он породил, таких как MVP и MVVM. В этом паттерне гораздо больше истории, чем заставляет верить текущая модная слова.
1
Из истории Model View Controller : «MVC был изобретен в Xerox Parc в 70-х годах, по-видимому, Тригве Реенскаугом. Я считаю, что его первое публичное появление было в Smalltalk-80. Долгое время практически не было публичной информации о MVC, даже в Smalltalk. Документация -80. Первой важной статьей, опубликованной на MVC, была «Поваренная книга по использованию парадигмы пользовательского интерфейса Model-View-Controller в Smalltalk -80», написанная Гленом Краснером и Стивеном Поупом, опубликованная в выпуске JournalOfObjectOrientedProgramming в августе / сентябре 1988 года. (JOOP) «.
Есть много гораздо более важных модных слов, таких как KISS, которые существуют дольше и привлекают к себе МЕНЬШЕ внимания.
Майкл Барбер