ASP.NET MVC против веб-клиентского программного обеспечения factory (WCSF)

Недавно я занимался изучением различных типов архитектур Model View, и вам нужно решить, какой из них следует использовать для будущего внутреннего развития. Поскольку я в настоящее время работаю в магазине Microsoft, обладающем навыками ASP.NET, кажется, что мои параметры находятся между ASP.NET MVC и WCSF (возможно, Monorail из-за того, что Microsoft не поддерживает его).

После прочтения структуры ASP.NET MVC, используя WCSF в качестве критерия, я подобрал следующие моменты:

  • ASP.NET MVC не может использовать веб-элементы управления, которые полагаются на postbacks, тогда как WCSF может.
  • У вас больше контроля над URL-адресами на сайте ASP.NET MVC, а не с сайтом WCSF.
  • Веб-сайт ASP.NET MVC, вероятно, будет легче протестировать, чем эквивалентная версия WCSF.
  • Кажется, что WCSF по-прежнему использует код для управления событиями пользовательского интерфейса при некоторых обстоятельствах, но ASP.NET MVC этого не допускает.

Каковы некоторые другие соображения?
Что я не понял?
Есть ли кто-нибудь, кто использовал оба фреймворка и имеет ли он какой-либо совет?

ОТВЕТЫ

Ответ 1

ASP.NET MVC не может использовать веб-элементы управления, которые полагаются на postbacks, тогда как 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.

Ответ 2

Не начать войну пламени, но я нашел, что WCSF достаточно запутан. Изящество и простота MVC сбрасывает MVP, который чувствует себя как образец, который просто прививается к веб-формам.

Ответ 3

Мы выбрали WCSF, выполнив точно такую ​​же оценку. Мы чувствовали, что шаблон MVP дал нам больше возможностей. I.e Возможность использовать серверные элементы управления. Наша команда разработчиков в основном состоит из программистов из множества дисциплин, таких как С++, Biztalk и web и т.д., Но все они были сосредоточены главным образом на разработке типа MS, поэтому кривая обучения при принятии шаблонов была не столько для нашей команды.

Мы более чем довольны нашим выбором.

Ответ 4

Вы также можете рассмотреть фон своих разработчиков (если они уже были идентифицированы).

Если они исходят из строгой базы asp.net, они будут более комфортными вокруг WCSF (хотя, по моему опыту, им по-прежнему понадобилось несколько недель, чтобы действительно было комфортно вокруг MVP).

Если они исходят из фона java/rails или раньше использовали другие архитектуры MVC, то, очевидно, они будут счастливее там (и по моему опыту очень заносчивы ни о чем другом, кроме MVC).

Ответ 5

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

Ответ 6

Сайт ASP.NET MVC, вероятно, будет легче протестировать, чем эквивалент Версия WCSF.

Это верно, потому что он использует новые классы абстракций для HttpContext, HttpRequest, HttpResponse и т.д. Там ничего по-видимому, более подверженному тестированию шаблона MVC, чем шаблон MVP. Они оба являются примерами "Разделенной презентации", и оба проверяемость.

Это, вероятно, спорно, но есть литература предложить, используя дизайн модели MVP легче unit test тогда дизайн модели MVC, если у вас есть взгляды, которые упакованы с логикой. Подводя итог, в проектной модели MVP Presenter обрабатывает работу, которая может обрабатываться View в модели MVC. Логика, которая может содержаться в MVC View, не облегчает модульное тестирование. Вот несколько ссылок на литературу, которые я прочитал, которые будут охватывать эту концепцию и причины, по которым ваш луч просмотра лучше по многим причинам, включая облегчение модульного тестирования.

http://martinfowler.com/eaaDev/uiArchs.html

http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://martinfowler.com/eaaDev/PassiveScreen.html

Ответ 7

Почему бы не присоединить обоих к Northwind и посмотреть, что лучше всего подходит для вас и вашей ситуации?