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

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-адрес указывает на представление), представления, естественно, будут реагировать на эти события. Они должны быть максимально простыми: звонить ведущему или предлагать события, на которые ведущий может подписаться.

Модель-представление-контроллер преодолевает это ограничение, позволяя внешнему миру взаимодействовать с контроллерами. Это означает, что ваши взгляды могут быть намного «глупее» в отношении вещей, не связанных с презентацией.

Что касается того, что вам следует использовать, я думаю, ответ сводится к тому, какой из них лучше всего подходит для целей вашего проекта. Иногда предпочтительнее использовать WebForms и доступность сторонних поставщиков средств управления, а в некоторых случаях грубая простота и мелкозернистый элемент управления HTML предпочтут MVC.

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

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

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

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

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

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

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

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

Это верно, потому что он использует новые классы абстракций для HttpContext, HttpRequest, HttpResponse и т. Д. В шаблоне MVC нет ничего более проверяемого, чем шаблон MVP. Оба они являются экземплярами «раздельной презентации», и оба повышают тестируемость.

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

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

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

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

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