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

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

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

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

15
model-view-controller n-tier-architecture

12 ответов

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

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

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

3

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

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

15

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

7

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

но если они будут, это будет время, чтобы переработайте их в MVC на них.

4

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

3

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

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

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

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

2

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

1

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

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

1

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

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

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

1

мы уже используем MVC для приложения Windows, Теперь нам нужно преобразовать эту вещь в веб-приложении, у нас нет никаких проблем ни в чем. Мы используем веб-сервис, и каждая бизнес-логика находится в веб-сервисе. Таким образом, вы можете использовать MVC в веб-приложении. М-модель(функции и процедуры, которые взаимодействуют с бизнес-логикой) V-View (Дизайн) C-Регулятор (Логика Формы) так что это не соединение в DAL, BLL и в MVC. вы можете определить свою бизнес-логику и использовать ее в любом месте в MVC. Это моя точка зрения MVC очень полезна для повторного использования я предпочитаю, если ваше приложение большое, то вы должны использовать MVC.

0

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

0
0