ASP.NET MVC против фабрики программного обеспечения веб-клиента (WCSF)
Недавно я провел небольшое исследование различных типов архитектур Model View, и мне нужно решить, какую из них использовать для будущей внутренней разработки. Поскольку в настоящее время я работаю в магазине Microsoft, обладающем навыками ASP.NET, кажется, что у меня есть выбор между ASP.NET MVC и WCSF (монорельсовая дорога, вероятно, исключена, так как она не будет поддерживаться Microsoft).
После прочтения ASP.NET MVC Framework, используя WCSF в качестве критерия, я поднял следующие моменты:
- ASP.NET MVC не может использовать веб-элементы управления, основанные на обратных передачах, тогда как WCSF может.
- У вас больше контроля над URL-адресами на сайте ASP.NET MVC, а не на сайте WCSF.
- Сайт ASP.NET MVC, вероятно, будет легче протестировать, чем эквивалентная версия WCSF.
- Похоже, что WCSF все еще использует код для управления событиями пользовательского интерфейса при некоторых обстоятельствах, но ASP.NET MVC этого не позволяет.
Каковы некоторые из других соображений?
Что я неправильно понял?
Есть ли кто-нибудь, кто использовал оба фреймворка и советовал в любом случае?
7 ответов
ASP.NET MVC не может использовать веб-элементы управления, основанные на обратных передачах, тогда как WCSF может.
Вы должны думать о WCSF как о руководстве по использованию существующей инфраструктуры WebForms, особенно о представлении Model-View-Presenter, которое поможет разделить проблемы. Это также увеличивает тестируемость полученного кода.
У вас больше контроля над URL-адресами на сайте ASP.NET MVC, а не на сайте WCSF.
Если вы можете использовать 3.5 SP1, вы можете использовать новую систему маршрутизации с традиционным сайтом WebForms. Маршрутизация не ограничивается MVC. Например, взгляните на Dynamic Data (который также поставляется в 3.5 SP1).
Сайт ASP.NET MVC, вероятно, будет легче протестировать, чем эквивалентная версия WCSF.
Это верно, потому что в нем используются новые классы абстракций для HttpContext, HttpRequest, HttpResponse и т. Д. Нет ничего более проверяемого в шаблоне MVC, чем шаблон MVP. Они оба являются экземплярами "Отдельной презентации", и оба повышают тестируемость.
Кажется, что WCSF по-прежнему использует код для управления событиями пользовательского интерфейса при некоторых обстоятельствах, но ASP.NET не позволяет этого.
В Model-View-Presenter, поскольку внешний мир взаимодействует с представлениями (т. Е. URL указывает на представление), представления естественно будут реагировать на эти события. Они должны быть как можно более простыми: позвонить докладчику или предложить события, на которые докладчик может подписаться.
Model-View-Controller преодолевает это ограничение, взаимодействуя с контроллерами внешнего мира. Это означает, что ваши взгляды могут быть намного "тупее" о вещах, не связанных с презентацией.
Что касается того, что вы должны использовать, я думаю, что ответ сводится к тому, какой из них лучше всего соответствует целям вашего проекта. Иногда предпочтение отдается WebForms и богатому доступному поставщику управления сторонних производителей, а в некоторых случаях грубая простота и детализированное управление HTML предпочтут MVC.
Не начинать пламенную войну, но я обнаружил, что WCSF довольно запутанный. Элегантность и простота MVC поражает MVP, который выглядит как шаблон, который только что привит на веб-формах.
Мы выбрали WCSF после той же оценки. Мы чувствовали, что шаблон MVP дал нам больше возможностей, т.е. возможность использовать серверные элементы управления. Наша команда разработчиков в основном состоит из программистов из множества дисциплин, таких как C++, Biztalk, Web и т. Д., Но все они были сосредоточены в основном на разработке типов MS, поэтому кривая обучения принятию шаблонов была не такой уж большой для нашей команды.
Мы более чем довольны нашим выбором.
MVC - намного более простая парадигма и больше похожа на то, как все другие фреймворки занимаются веб-разработкой. WebForms просто слишком много перепрыгивают через обручи и слишком много уровней абстракции, чтобы попытаться достичь простоты. ИМХО, через несколько лет MVC станет архитектурой ASP.NET по умолчанию, поскольку все больше и больше людей осознают простоту и легкость разработки и тестирования, которые она приносит с нами. Я занимаюсь разработкой MVC уже полтора года и даже не думаю о том, чтобы вернуться к WebForms в новом проекте.
Вы могли бы также рассмотреть фоны ваших разработчиков (если таковые уже были определены).
Если они имеют строгий опыт работы с asp.net, они будут чувствовать себя более комфортно в WCSF (хотя, по моему опыту, им все же потребовалось несколько недель, чтобы действительно чувствовать себя комфортно в MVP).
Если они пришли из java/rails фона или ранее использовали другие архитектуры MVC, то, очевидно, они там будут счастливее (и, по моему опыту, очень насмехаются над чем-то, кроме MVC).
Сайт ASP.NET MVC, вероятно, будет легче протестировать, чем эквивалентная версия WCSF.
Это верно, потому что в нем используются новые классы абстракций для HttpContext, HttpRequest, HttpResponse и т. Д. Нет ничего более проверяемого в шаблоне MVC, чем шаблон MVP. Они оба являются экземплярами "Отдельной презентации", и оба повышают тестируемость.
Это, вероятно, спорно, но есть литература предложить используя дизайн модели MVP легче модульного тестирования затем модель MVC дизайн, если у вас есть взгляды, которые упакованы с логикой. Подводя итог, можно сказать, что в модели проектирования MVP Presenter обрабатывает работу, которую может выполнять представление в модели проектирования MVC. Логика, которая может содержаться в MVC View, не облегчает модульное тестирование. Вот некоторые ссылки на литературу, которую я читал, которая охватывала бы эту концепцию, и причины, по которым сохранение вашего View View лучше по многим причинам, включая облегчение модульного тестирования.
http://martinfowler.com/eaaDev/uiArchs.html
Почему бы не присоединиться к Northwind и посмотреть, что подходит вам и вашей ситуации?