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

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

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

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

Ответы

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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