ASP.NET MVC по сравнению с Фабрикой программного обеспечения веб-клиента (WCSF)
Хорошо, я разработал способ:
element.addEventListener('animationend', function(e){
if(e.animationName === 'nameOfYourAnimation'{
//do something...
}
});
Красиво !!
6 ответов
ASP.NET MVC не может использовать веб-элементы управления, которые полагаются на обратные передачи, тогда как WCSF может.
необходимо думать о WCSF как о руководстве о том, как использовать существующую инфраструктуру WebForms, особенно представляя Образцового Предъявителя Представления, чтобы помочь осуществить разделение проблем. Это также увеличивает тестируемость получающегося кода.
Вы имеете больше контроля над URL в сайте MVC ASP.NET в противоположность сайту WCSF.
, Если можно быть нацелены на 3,5 SP1, можно использовать новую Систему маршрутизации с традиционным сайтом WebForms. Маршрутизация не ограничена MVC. Например, смотрите на Динамические Данные (который также поставлется в 3,5 SP1).
сайт MVC ASP.NET, вероятно, будет легче протестировать, чем эквивалентная версия WCSF.
Это верно, потому что это использует новые классы абстракций для HttpContext, HttpRequest, HttpResponse, и т.д. Нет ничего по сути более тестируемого о шаблоне MVC, чем шаблон MVP. Они - оба экземпляры "Разделенного Представления" и обе тестируемости увеличения.
кажется, что WCSF все еще использует код позади для управления событиями UI при некоторых обстоятельствах, но ASP.NET не позволяет это.
В Образцовом Предъявителе Представления, так как внешний мир взаимодействует с представлениями (т.е. URL указывает на представление), представления будут естественно отвечать на эти события. Они должны быть максимально простыми, или путем вызова предъявителя или путем предложения событий, на которые может подписаться предъявитель.
Образцовый Контроллер Представления преодолевает это ограничение при наличии внешнего мира, взаимодействуют с контроллерами. Это означает, что Ваши представления могут быть намного "более немыми" о вещах непредставления.
, Что касается которого необходимо использовать, я думаю, что ответ сводится, какой лучше всего удовлетворяет целям проекта. Иногда WebForms и богатая сторонняя доступность поставщика управления будут предпочтительны, и в некоторых случаях, необработанная простота и мелкомодульное управление HTML будут способствовать MVC.
Почему бы не присоединить и к Northwind и видеть, который подходит лучше всего для Вас и Вашей ситуации?
Мы выбрали WCSF после выполнения точно той же оценки. Мы чувствовали, что шаблон MVP дал нам больше опций т.е. Способности использовать управление сервером. Наша группа разработчиков главным образом составлена из Программистов от несметного числа дисциплин т.е. C++, Biztalk и сети и т.д., но все сфокусировалась главным образом на разработке типа MS, таким образом, кривая обучения в принятии шаблонов не была так для нашей команды.
Мы более, чем довольны нашим выбором.
Вы могли бы также рассмотреть фон своих разработчиков (если кто-либо был уже определен).
, Если они происходят из строгой среды asp.net, они будут более удобными вокруг WCSF (хотя, по моему опыту, все еще им потребовались несколько недель, чтобы действительно быть удобным вокруг MVP).
, Если они происходят из среды Java/направляющих или использовали другую архитектуру MVC прежде, тогда очевидно, они будут более счастливыми там (и по моему опыту станут очень задиристыми о чем-либо кроме MVC).
Не для того, чтобы начинать огненную войну, но я нашел WCSF довольно запутанным. Элегантность и простота MVC поражает MVP, который кажется шаблоном, просто привитым к веб-формам.
MVC is a much simpler paradigm and is more similar to how all other frameworks do web development. WebForms is simply way too much jumping through hoops and too many layers of abstraction to try and achieve simplicity. IMHO, MVC will be the default ASP.NET architecture within a few years, as more and more people realize the simplicity and ease of development and testing that it brings with us. I have been doing MVC development for a year and a half and would never even think of going back to WebForms on a new project.