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

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

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

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

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

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

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

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

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

На мой взгляд, существует два типа 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 для лучшей организации кодовой базы.

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

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

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

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

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

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

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

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

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

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

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