Когда НЕ использовать MVC в веб-приложении?

Question

Я работал над наброском некоторых идей для нового проекта и понял, что у меня возникли некоторые трудности с получением элементов, подходящих для инфраструктуры MVC (в данном случае, CodeIgniter). Хотя я верил, что это можно преодолеть, немного поработав с дизайном и придумав лучший макет, я подумал: может ли MVC не быть лучшим ответом здесь? и если нет, то когда использование MVC является хорошей идеей для проекта, а когда - нет?

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

Answer 1

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

MVC - это просто шаблон, который хорошо подходит для Интернета. В частности, это хорошо относится к идее, что к приложению обращаются следующим образом:

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

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

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

Answer 2

Когда это одностраничное приложение .

(на самом деле все же стоит разделять проблемы и делать MVC в малом, но это не MVC в смысле PHP-сервера)

Answer 3

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

Answer 4

Вот несколько приложений, в которых двухуровневая или трехуровневая архитектура является более подходящей:

• Ссылка агрегатора
• Генератор коротких ссылок
• Панель администратора веб-хостинга
• Веб-IDE
• конвертер веб-изображений
• Интерфейс принтера
• Генератор PDF
• Приложение чата
• Система контроля версий

Вот некоторые другие альтернативы Model => View => Controller:

1. Двухуровневая архитектура

2. Трехуровневая архитектура

3. Четырехуровневая архитектура

4. Шестиугольная архитектура

5. Шаблонно-ориентированная архитектура программного обеспечения

6. Общие сведения о шаблонах для интеграции систем (pdf)

7. Презентация-абстракция-контроль

8. Microkernel

9. трубоукладчика и-фильтр

10. Peer-к-Peer

11. Модульное ядро ​​

12. Гибридное ядро ​​

13. ядро ​​монолитное

14. экзоядро

Ссылки

• Ориентация на программные среды Oracle (pdf)

• Обзор разработки приложения базы данных Oracle

• Перемещение клиента / сервера в Интернет

• Шаблоны и практики Microsoft: Шаблоны распределенных систем

• Руководство по архитектуре приложений Microsoft, 2-е издание

• Многоуровневое распределение

Answer 5

По сути, MVC хорошо работает, когда у вас есть приложение, которое требует разделения данных (модель), обработки данных (контроллер) и представления данных (представление). Это также хорошо работает в приложении, где источник данных и / или представление данных могут измениться в любое время. Таким образом, данные могут поступать из БД, RSS-канала, Twitter API и т. Д. И могут быть представлены в виде RSS-канала, обычного XHTML, мобильной версии и т. Д. Разделив приложение на три слоя, вы можете разработать для всех этих различные сценарии, просто создав соответствующий вид или модель.

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

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

Answer 6

РЕДАКТИРОВАТЬ: Я заметил тег PHP только после ответа на вопрос, однако, прочитайте комментарии, поскольку первоначальный вопросник нашел ссылку полезной, поэтому я оставлю этот ответ здесь.

Джеффри Палермо (один из авторов ASP.NET MVC в действии ) имеет пост в блоге, обсуждающий эту самую вещь:

Вы не должны использовать ASP.NET MVC, если. , .

Он заявляет, что вам НЕ следует использовать ASP.NET MVC, если:

• Вам не очень комфортно с полиморфизмом
• Вы не хотите строить поверх фреймворка
• Вы полагаетесь на элементы управления сторонних поставщиков для большого количества пользовательского интерфейса
• Вы не хотите использовать библиотеки с открытым исходным кодом

Я думаю, что большой «стоп-сигнал» в этом списке может заключаться в использовании сторонних элементов управления (в частности, замен GridView и т. Д.), Которые не очень хорошо работают с платформой MVC (т.е. внутренние элементы управления используют Viewstate) и / или постбэки). Возможно, вы работаете в компании, которая обязывает использовать какой-либо сторонний элемент управления для обработки определенных функциональных возможностей веб-компонента (наиболее очевидным из представленных элементов управления GridView или Calendar), а не «встроенный» ASP Элементы управления .NET, обеспечивающие аналогичную функциональность. Действительно, многие из более сложных встроенных элементов управления, основанных на ASP.NET WebForms, не очень хорошо работают с моделью MVC из-за их зависимости от состояния представления / обратных передач и других неподдерживаемых функций модели MVC.

Кроме того, если приложение ASP.NET, которое вы создаете, невероятно маленькое и тесно ориентировано на одну функцию, его можно было бы быстрее разработать с использованием более «традиционной» платформы WebForms, а не MVC, однако для чего-то большего (то есть, вероятно, большинство коммерческих / корпоративных приложений) MVC, возможно, является лучшим выбором, так как он обеспечивает гораздо большую тестируемость создаваемого кода и способствует лучшему разделению проблем.

Answer 7

Значение MVC быстро исчезает, когда оно ...

1. Проект с одним разработчиком или небольшой командой, работающей на одном языке кодирования
2. Проект с одним интерфейсом (например, только для настольной версии)
3. Проект с богатым пользовательским интерфейсом, код в основном на стороне клиента и батарея вызовов AJAX
4. Все, что не является веб-сайтом (например, фид данных, утилиты и т. Д.)
5. Любой проект, в котором члены команды не заботятся о том, чтобы в их резюме было «MVC»
6. Любой проект через 5 лет, когда MVC начинает выходить из моды

Answer 8

Честно говоря, я не могу вспомнить ни одного сценария, в котором было бы нецелесообразно использовать подход MVC. Это просто концепция - методология, позволяющая четко разделить различные части вашего кода логичным и стандартизированным способом.

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

Не могли бы вы объяснить немного больше о том, что вы имеете в виду, когда говорите:

"... и понял, что у меня есть некоторые Трудно заставить вещи вписаться в рамки MVC "

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