Причины не использовать архитектуру MVC для веб-приложений

Question

В прошлом я прежде всего создавал все свои веб-приложения, используя N-уровневую архитектуру, реализуя уровни BLL и DAL. Недавно я начал заниматься разработкой RoR, а также изучал ASP.NET MVC.

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

Есть ли у вас какие-либо причины / времена, когда архитектура MVC не подходит, или какие-либо причины, по которым вы бы выбрали вместо этого архитектуру BLL / DAL?

Answer 1

Я не думаю, что ваши варианты являются взаимоисключающими. Вы могли бы прекрасно использовать MVC при использовании BLL / DAL для логики модели.

Вы можете реализовать часть M MVC по своему усмотрению, здесь нет никаких ограничений. Использование BLL и DAL будет допустимым вариантом.

Answer 2

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

Answer 3

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

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

MVC - это просто способ организации кода, как это делают BLL или DAL. MVC в Rails в основном скрывает DAL, используя набор соглашений. Обычно бизнес-логика находится в самих моделях. Однако, если ваше приложение требует более сложных BLL, где взаимодействие объектов может быть сложным, то нет никаких причин, по которым этот BLL не может мирно сосуществовать с M в MVC.

Answer 4

Я не использую MVC только в действительно крошечных проектах, состоящих из ~ 1-2 файлов и ~ 10-20 строк кода. И вряд ли они превратятся в нечто большее.

Но если они это сделают, пришло время перестроить их в MVC.

Answer 5

Единственный недостаток, который у нас был, - это то, что MVC подталкивает вас к интерфейсу html / javascript, где насыщенные интернет-приложения становятся все труднее. Например, если вы хотите предоставить пользователю элемент управления календаря, вам может понадобиться свернуть свой собственный, поскольку вы не можете добавить его из панели инструментов. Тем не менее, MVC это здорово. Когда нам действительно нужны приложения RIA, мы используем MVVM и Silverlight.

Answer 6

Для определенных страниц MVC может быть немного излишним:

• заставочные страницы
• целевые страницы
• маркетинговые страницы, которые будут выброшены после однойиспользуйте
• одноразовые

Легко запутаться, создав красивую архитектуру MVC, когда небольшая страница, кратко написанная, может быть в порядке в этих ситуациях.

MVC также может быть непрактичным, если у вас проблемы со временем, и вам нужно что-то ДЕЙСТВИТЕЛЬНО быстро.Как будто ваша маркетинговая команда на конференции, у них проблемы, и им нужно что-то показать на своем стенде в эту секунду, прежде чем они потеряют своего крупнейшего клиента.

Answer 7

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

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

Как сказал один из авторов, вы также должны учитывать состояние любых существующих приложений и навыки / опыт вашей команды разработчиков.

Answer 8

Простой ответ: нет.

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

Answer 9

Жизнь выше уровня обслуживания предполагает, что вы должны использовать шаблон MVC таким образом, чтобы он соответствовал принципам SOFEA, и остерегаться структур типа "Front controller", маскирующихся под аббревиатурой MVC.(или вы все равно можете их использовать, но хотя бы прочитайте статью, поймите различия и сделайте мудрый выбор).

Answer 10

Вы можете обратиться к следующим

http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx

и http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 см. «Неоспоримые факты».