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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Агрегатор ссылок
Генератор коротких ссылок
Панель администрирования веб-хостинга
Web IDE
Конвертер веб-изображений
Frontend принтера
Генератор PDF
Приложение чата
Система контроля версий

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

Ссылки

Ответ 7

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

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

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

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

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

Ответ 8

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

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