Каковы недостатки MVC? [закрыто]

43

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

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

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

Оскар Годсон
источник
5
Есть слишком много возможных ответов, или хорошие ответы будут слишком длинными для этого формата. Пожалуйста, добавьте детали, чтобы сузить набор ответов или выделить проблему, на которую можно ответить в нескольких параграфах.
комнат
8
Мне нужен ответ о том, каково ваше определение MVC, прежде чем я смогу ответить на ваш вопрос, поскольку архитектура MVC применима только к набору проблем, как есть. Так что, если вы используете его не в том месте, у вас будет падение.
Бен Макдугалл
1
Насколько разнообразны ваши разные работы?
JeffO
@JeffO PHP-приложения (бэкенд, не-JS тяжелые сайты), интерфейсные приложения. Итак, все сети, но фронтенд и бэкэнд.
Оскар Годсон

Ответы:

46

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

Это была моя самая большая ошибка. Я потратил много времени на понимание этого простого правила:

  • Не распространяйте шаблон MVC среди всего приложения,
  • Ограничьте это только пользовательским интерфейсом.

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

Все шаблоны, которые вы называете MVC-альтернативами (то есть Model-View-Presenter, Model-View-ViewModel), являются лишь способом реализации общей концепции MVC.

Hedin
источник
10
на самом деле вы можете реализовать MVC в любое время, когда у вас есть уровень абстракции; API - это представление / контроллер, а лежащая в основе логика - это модель
трещотка урод
14
@ratchetfreak, технически говоря, API - это форма пользовательского интерфейса, где пользователь является программистом, использующим API.
zzzzBov
@ratchetfreak: не будет ли это классифицироваться как фасадный рисунок?
Йерун Ванневел
2
MVC может быть наиболее полезным в пользовательском интерфейсе, но его разделение интересов едва ли полезно там.
DougM
1
@ DougM правда. более конкретно: особый стиль разделения в MVC был создан для приложений с графическим интерфейсом. позже концепция была расширена до веб-приложений, потеряв большую специфику. расширение его до конструкций API делает его еще более расплывчатым. помимо этого ... я думаю, что он теряет большую часть своей ценности, и было бы лучше начать заново с более базовой (и универсальной) концепции разделения интересов.
Хавьер
17

На мой взгляд, существует два типа MVC - чистый и нечистый (из-за отсутствия лучшего слова :)

Чистый MVC - это то, что было введено в светскую беседу:

введите описание изображения здесь

Это было предназначено для персональных компьютеров / настольных приложений. Как видите, модель информирует мнения о любых обновлениях / изменениях, внесенных в нее. Не так с (нечистым) MVC.

Другой (нечистый) MVC, рекламируемый для веб-приложений, - это скорее шаблон PAC ( Presentation-abstraction-control ) вместо классического MVC, описанного выше. Это больше касается организации кода и разделения интересов:

  • Модель : абстракция для хранимых данных
  • Управление : обычно то, что известно как уровень бизнес-логики, а также часть приложения, отвечающая за маршрутизацию HTTP-запросов к соответствующей бизнес-логике (он же контроллер)
  • Просмотр : в основном просмотр шаблонов, которые форматируют данные из модели и возвращают их клиенту. Модель НИКОГДА не отправляет обновления представлению, а также представление не подписывается на обновления от модели. Это был бы кошмар. Следовательно, это больше похоже на PAC, чем на настоящий MVC.

Теперь, как обычно структурируется веб-приложение:

  1. Front-end : MVC на клиенте, использующем фреймворки как Backbone.js и т. Д., По сути, это «истинная» форма MVC.
  2. Back-end : Опять же, у вас есть (нечистый) MVC / PAC для организации кода и разделения проблем
  3. Глобальное веб-приложение (для веб-приложения в целом): если у вас есть бэкэнд RESTful, который возвращает только данные JSON, тогда весь ваш бэкэнд может восприниматься как модель для клиентского приложения внешнего интерфейса, где по сути находятся View и Controller.

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

Вы должны использовать это везде? Возможно, нет. Чрезвычайно сложные веб-приложения могут быть разбиты на несколько слоев! Возможно, вам не удастся уйти с помощью только слоев View / Business Logic / Data. Всеобъемлющей структурой / организацией все еще может быть MVC, но только на макроскопическом уровне.

Вот пример, где просто MVC сам по себе может быть плохим выбором : попробуйте разработать систему управления воздушным движением или приложение для обработки кредита / ипотеки для крупного банка - просто MVC сам по себе был бы плохим выбором. У вас неизбежно появятся шины событий / очереди сообщений, а также многоуровневая архитектура с MVC на отдельных уровнях и, возможно, всеобъемлющий дизайн MVC / PAC для лучшей организации кодовой базы.

кандидат наук
источник
+1 за «чистое против нечистого». хотя я предпочитаю использовать «GUI vs Web MVC» и указать, что GUI MVC является модульным, а Web MVC является многоуровневым . Мне бы очень хотелось, чтобы Web MVC назывался как-то иначе, поскольку он слишком отличается от «чистого MVC», но, похоже, для этого уже слишком поздно.
Хавьер
Мне нравится диаграмма. Число рейнольдса формулировка, может быть, «традиционный MVC против производного MVC» :)
Эдвин Ип
12

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

Если вы какое-то время работали в одном месте, вы можете почти датировать фрагмент кода, посмотрев, какие технологии / шаблоны проектирования / практики были в моде в то время, например, одиночные игры / внедрение зависимостей / TDD и т. Д. И т. Д. И т. Д.

Что касается того, где не использовать его. Хорошо, где один элемент триплета MVC не применяется. Консольные приложения могут вообще не реализовывать интерфейс. У служебных программ может не быть модели. И, возможно, если у вас нет ни модели, ни вида, вам не требуется контроллер.

Проблема редко с концепцией - больше с реализацией. Независимо от того, насколько хороша парадигма, найдите время, чтобы убедиться, что она хорошо подходит для рассматриваемой проблемы.

Робби Ди
источник
2
MVC, при правильном соблюдении, допускает повторное использование кода. та же логика, лежащая в основе утилиты или проекта командной строки, может легко быть идентичным контроллером из более крупной программы с альтернативной моделью и представлением. (такой, возможно, не самый эффективный код, но это не всегда вызывает беспокойство.)
DougM
Консоль - это пользовательский интерфейс. Просто на основе текста, поэтому ваше предположение неверно.
GuardianX
@GuardianX Я не очень хорошо сказал это слово. Я отредактировал свой ответ, чтобы уточнить.
Робби Ди
3

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

Альтернативой для первой проблемы является разделение такого кода на независимые подпроекты; альтернативой для второго является неразделенный код либо в классе, либо в файловой модели.

DougM
источник
+1 за упоминание небольших проектов, хотя я ценю, что здесь есть разные школы мысли. Некоторые скажут, что если есть вероятность, что POC может превратиться в живой код, он должен быть написан правильно. В то время как другие говорят, что вместо того, чтобы рисковать тратить время на полировку чего-то, что никогда не может быть использовано, было бы лучше сгладить что-то вместе, а затем начать все сначала, если проект продолжится.
Робби Ди
@Robbie: ааа !! черт побери!
DougM
0

В моем понимании применения MVC / MV * я придерживаюсь принципа разделения проблем (SoC) - разделения программы / кодов на отдельные разделы / фрагменты, чтобы каждый раздел мог решать отдельную проблему (ссылка: http://en.wikipedia.org / wiki / Separation_of_concerns )

при разделении задач есть много преимуществ: одно не повлияет на другое, и разработчики могут работать над модулем, не влияя на остальные и т. д. и т. д. ... MVC - не единственный шаблон, который следует за SoC, в основном, сам ООП отличная концепция, чтобы разбить вещи на части.

MVC / MV * очень полезны при работе с разработкой, связанной с пользовательским интерфейсом, хотя под ними может быть больше шаблонов - фабрика, синглтон, фасад и т. Д. Большинство крупных проектов состоят из нескольких слоев, работающих с различными аспектами, но пользовательский интерфейс может не быть обязательным для некоторые случаи. Вы можете часто видеть MVC - это потому, что многие проекты имеют элементы пользовательского интерфейса.

Таким образом, говоря о недостатках MVC, это действительно зависит от проектов, которые вы делаете - есть ли у него интерфейс? это требует большой масштабируемости / расширяемости? Есть ли много взаимодействий между пользовательским интерфейсом и внутри системы? например, простая информационная веб-страница вообще не требует MVC, если только вы не планируете расширить ее до великолепной интерактивной страницы в будущем.

поэтому для оценки MVC (или, более общего - шаблона проектирования), создайте для него контекст и подумайте о сложности, масштабируемости, тестируемости, обслуживании, ограниченности времени и т. д. и т. д.

Rex
источник