Где MVC является плохой вещью?

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

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

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

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

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

Приложение WebDAV также не выиграет от MVC.

Предостережение на Ruby для веб-программирования состоит в том, что Rails лучше подходит для создания веб-приложений. Я видел много проектов, которые пытались создать сервер WebDAV или CMS системы управления контентом с Rails и терпели неудачу. Хотя вы можете создать CMS в Rails, существуют гораздо более эффективные технологии для этой задачи, такие как Drupal и Django. Фактически, я бы сказал, что если вы смотрите на разработку портала Java, вам следует вместо этого оценить Drupal и Django для этой задачи.

Все, что вы хотите добавить в сторонние компоненты, затруднит работу в шаблоне MVC. Хорошим примером этого является CMS.

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

Когда это плохо? Где бы ни существовала другая структура кода, которая лучше подошла бы вашему проекту.

Есть бесчисленное множество проектов, в которых MVC «не подходит», но я не понимаю, как их список может быть полезен ..

] Если MVC подходит, используйте его, если нет, используйте что-нибудь другое ..

Я не обязательно знаю, что MVC когда-либо действительно плохая идея для приложения с графическим интерфейсом. Но есть альтернативы, которые, возможно, лучше (а также, возможно, хуже, в зависимости от того, чье мнение вы спрашиваете). Самый распространенный - это MVP. См. Объяснение здесь: Все, что вы хотели знать о MVC и MVP, но боялись спросить .

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

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

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

MVC и ORM - это шутка .... они подходят только тогда, когда ваше приложение не является приложением базы данных. , или когда вы хотите, чтобы база данных приложения оставалась независимой. Если вы используете СУБД, которая поддерживает хранимые процедуры, то это единственный выход. Сохраненные процессы являются предпочтительным подходом для опытных разработчиков приложений. MVC и ORM продвигаются только компаниями, пытающимися продавать продукты или услуги, связанные с этими технологиями (например, Microsoft пытается продать VS). Хватит тратить время на изучение Java и C#, вместо этого сосредоточьтесь на том, что действительно важно, на Javascript и SQL.