Причины не использовать архитектуру MVC для веб-приложения
В прошлом я, прежде всего, создал все свои веб-приложения с помощью архитектуры N-tier, реализовав уровни BLL и DAL. Недавно, я начал делать некоторую разработку RoR, а также изучать ASP.NET MVC.
Я понимаю, различия между различной архитектурой (как ссылается некоторым другим ТАК отправляет), но я не могу действительно думать ни о каких причинах, почему я не выбрал бы модель MVC, продвигающуюся для нового проекта.
Есть ли какие-либо причины/времена, по вашему опыту, когда архитектура MVC не подошла бы, или никакие причины, почему Вы выберете архитектуру BLL/DAL вместо этого?
10 ответов
Одним из факторов может быть состояние вашего веб-приложения. Если это базовое веб-приложение, которое получает все от сервера с несколькими крючками JavaScript, такими как валидация на стороне клиента, то MVC типа Rails действительно великолепен. Я не знаком с MVC на ASP.NET, но слышал, что он похож на тот, что в Rails.
Если веб-приложение является действительно государственным, то лучшим подходом будет двойной слой MVC - один на стороне клиента, а другой для сервера. MVC на сервере будет в основном заниматься аутентификацией, авторизацией, выдачей данных в стандартных форматах и т.д. MVC на стороне клиента будет заниматься такими вещами, как события DOM, действия пользователя, как они влияют на состояние приложения, и как/когда данные должны быть запрошены/отправлены на сервер.
MVC - это просто способ организации кода, точно так же, как это делают BLL или DAL. MVC в Rails, по сути, полностью скрывает DAL, используя набор соглашений. Обычно бизнес-логика располагается в самих моделях. Однако, если ваше приложение требует более сложного BLL, где взаимодействие объектов может быть замысловатым, то нет причин, почему этот BLL не может мирно сосуществовать с M в MVC.
Я не думаю, что ваши варианты являются взаимоисключающими. Вы можете отлично использовать MVC при использовании BLL / DAL для своей логики модели.
Вы можете реализовать часть MVC M по своему усмотрению, на это нет никаких ограничений. Допустимым вариантом будет использование BLL и DAL.
Для меня? Единственная причина, по которой я не стал бы использовать MVC, - это то, что приложение, над которым я работаю, уже было запущено в веб-формах. Я не большой сторонник утилизации / перезаписи, но все новое, что я делаю, находится в MVC.
Я не использую MVC только в очень маленьких проектах, состоящих из ~ 1-2 файлов и ~ 10-20 строк кода. И вряд ли они превратятся в нечто большее.
Но если они захотят, то пора будет преобразовать их в MVC.
Мы уже использовали MVC для Windows-приложения, теперь нам нужно преобразовать это в Web-приложение, и у нас нет никаких проблем. Мы используем веб-сервис, и вся бизнес-логика находится в веб-сервисе. Поэтому вы можете использовать MVC в веб-приложении. M-Model (функции и процедуры, которые взаимодействуют с бизнес-логикой) V-View (дизайн) C-Controller (логика формы) Таким образом, нет никакой связи между DAL, BLL и MVC. Вы можете определить свою бизнес-логику и использовать ее в любом месте MVC. Это моя точка зрения, MVC очень полезен для повторного использования, и если ваше приложение большое, то вы должны использовать MVC.
Единственный недостаток, с которым мы столкнулись, это то, что MVC толкает вас к интерфейсу html/javascript, где богатые интернет-приложения становятся более сложными. Например, если вы хотите представить пользователю элемент управления календарем, вам, возможно, придется создавать свой собственный, поскольку вы не можете добавить его из панели инструментов. Тем не менее, MVC - это здорово. Когда нам действительно нужны RIA-приложения, мы используем MVVM и Silverlight.
Я бы не стал использовать шаблон MVC только в том случае, если у меня есть существующее настольное приложение, созданное с помощью MVP, и мне нужно преобразовать его в веб-среду. Это потому, что я уже написал логику для ведущего.
В любом другом случае я бы использовал MVC.
Срок службы выше уровня обслуживания предполагает, что вам следует использовать шаблон MVC таким образом, чтобы он соответствовал принципам SOFEA, и остерегайтесь фреймворков типа «Front Controller», маскирующихся за аббревиатурой MVC. . (или вы все еще можете их использовать, но, по крайней мере, прочитайте статью, поймите различия и сделайте правильный выбор).
Лично я бы оценил его по сложности целевого приложения. MVC (или более структурированные подходы в целом) очень хорошо подходят для крупномасштабных приложений, где согласованность дизайна и разделение кода являются преимуществом, перевешивающим затраты на поддержку дизайна.
Если это небольшой сайт или очень мало страниц / элементов управления, я бы не стал придерживаться строгих шаблонов проектирования. Но это только мое предпочтение.
Как сказал один из авторов, вы также должны учитывать состояние любых существующих приложений и навыки / опыт вашей команды разработчиков.
Простой ответ, нет.
MVC - это лучшая архитектура, чем ваша старая многоуровневая архитектура, по многим причинам. Это стандартный подход в других моделях пользовательского интерфейса (например, Swing). Единственная причина, по которой понадобилось так много времени, чтобы добраться до веб-приложений, заключалась в том, что сообществу разработчиков программного обеспечения потребовалось некоторое время, чтобы привыкнуть к безгражданству Интернета и иметь возможность работать с представлениями и контроллерами таким образом, чтобы имело смысл.