Когда отдавать предпочтение ASP.NET WebForms, а не MVC

Я знаю, что Microsoft сказала

ASP.NET MVC не является заменой веб-форм.

А некоторые разработчики говорят, что WebForms быстрее разрабатывается, чем MVC. Но я считаю, что скорость кодирования сводится к уровню комфорта с технологией, поэтому я не хочу никаких ответов в этом ключе.

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

Webforms vs. MVC сейчас, кажется, горячая тема. Все, кого я знаю, рекламируют MVC, чтобы быть следующей великой вещью. Судя по моим небольшим увлечениям, все в порядке, но нет, я не думаю, что это конец веб-форм.

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

Время / деньги - это главные причины, по которым веб-формы выбираются вместо MVC.

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

Если у вас большой веб-сайт, на котором все написано в веб-формах, возможно, вы будете более склонны создавать новые страницы в веб-формах, чтобы на вашем сайте не было двух совершенно разных типов страниц.

Я не говорю, что здесь используется подход «все или ничего», но он усложняет поддержку вашего кода, если есть разделение обоих, особенно если не все в команде знакомы с MVC.

Моя компания недавно сделала три тестовые страницы с MVC. Мы сели и разработали их. Одна из проблем, с которой мы столкнулись, заключается в том, что большинство наших экранов имеют функции просмотра и редактирования на одной странице. Нам понадобилось более одной формы на странице. Ничего страшного, кроме того, что мы не будем использовать нашу мастер-страницу. Нам пришлось обновить его, чтобы страницы веб-форм и страницы MVC могли использовать одну и ту же мастер-страницу для общего внешнего вида. Теперь у нас есть дополнительный слой вложенности.

Нам нужно было создать совершенно новую структуру папок для этих страниц, чтобы она соответствовала правильному разделению MVC.

Я чувствовал, что было слишком много файлов для 3 страниц, но это мое личное мнение.

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

Я разрабатывал приложения ASP .Net WebForms в течение 3 лет, и после одного дня занятий по MVC меня продали. MVC почти всегда лучшее решение. Почему?

• Страница lifecylce проще и эффективнее
• Существует нет такой вещи, как элементы управления, кроме элементов управления HTML. Вам не нужно отлаживать вывод, чтобы увидеть, что генерирует ASP .Net.
• ViewModels дает вам огромную мощность и избавляет от необходимости выполнять привязку ручного управления, и это устраняет множество ошибок, связанных с привязкой.
• Вы можете иметь несколько форм на странице. Это было серьезным ограничением веб-форм.
• Сеть не имеет состояния, и MVC более точно соответствует архитектуре сети. Webforms представляет состояние и ошибки, которые у вас есть с ним, представляя ViewState. ViewState является автоматическим и работает в фоновом режиме, поэтому он не всегда ведет себя так, как вы этого хотите.
• В наши дни веб-приложения должны работать с ajax. Недопустимо иметь полную загрузку страницы. MVC делает AJAX намного лучше, проще и эффективнее с JQuery.
• Поскольку у вас может быть несколько форм на странице, и поскольку архитектура управляется вызовами URL-адресов, вы можете делать такие вещи, как ajax, загружать другую форму, например, форму редактирования на вашу текущую страницу, используя JQuery. Как только вы поймете, что это позволяет вам, вы сможете легко делать удивительные вещи.
• ASP .Net WebForms - это не только абстракция над html, но и чрезвычайно сложная. Иногда вы получаете странную ошибку и боретесь с ней гораздо дольше, чем нужно. Во многих случаях вы можете увидеть, что он делал неправильно, но вы ничего не можете с этим поделать. В итоге вы делаете странные обходные пути.
• WebForms не делает хорошую технологию для дизайнеров. Дизайнеры часто любят работать с HTML напрямую. В MVC это вид, в WebForms это полдня работы.
• Поскольку веб-платформа развивается, быстрые WebForms не будут отставать. Он не знает о новых тегах или функциях HTML5, он все равно будет отображать те же вещи, если вы не получите (часто) дорогостоящие сторонние элементы управления или подождите, пока Microsoft выпустит обновление.
• Элементы управления в WebForms ограничивают вас во многих отношениях. В MVC вы можете просто взять библиотеку JQuery и интегрировать ее в свои шаблоны.

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

Я написал Скотту Гатри , эксперту MVC в Microsoft. И, наверное, самый квалифицированный человек, чтобы ответить на этот вопрос. Он был достаточно любезен, чтобы ответить:

«Разные клиенты ищут разные подходы к программированию, и многие любят веб-формы и думают, что это здорово. Другие любят MVC и думают, что это здорово. Именно поэтому мы вкладываем средства в оба».

Итак, для меня это говорит о том, что это не техническая проблема. Это скорее «мягкий вопрос», если хотите. Одно из личных предпочтений. Это соответствует тому, что говорили некоторые из вас.

Спасибо за ответы на все вопросы.

Это устаревший вопрос с множеством ответов, но ни один из них не дал ответа, который я ожидал бы найти в списке.

Краткий ответ:

• Используйте ASP.NET MVC, если вы хотите правильно построить веб-приложение с современными соглашениями о программировании и принятыми в отрасли шаблонами для платформы ASP.NET. С другой стороны, вы должны будете знать, как работают HTML и клиентские ресурсы (Javascript, CSS), а также как нарастить мышление в MVC-программировании, которое имеет крутую кривую обучения, но достигает внезапного конца после того, как его освоили.
• Используйте веб-формы ASP.NET, если вы используете или хотите использовать GUI- ориентированный подход , RAD (Rapid Application Development) , метод перетаскивания мышью для быстрого прототипирования чего-либо, то есть поведение кнопки / сетки данных, связанное внутри 15 минут, и решение не предназначено для поддержки разработчиков. Или используйте веб-формы ASP.NET, если у вас есть опыт разработки GUI или Windows Forms и вы хотите перенести свои знания в Интернет.

Но чтобы посмотреть на это должным образом, вы должны понимать историю каждого.

Веб-формы ASP.NET были ответом Microsoft тем, кто создавал динамические веб-приложения, используя элементы управления ActiveX Visual Basic 6, библиотеки DLL VB6 на сервере и ASP Classic. В то время веб-разработка с использованием этих инструментов Microsoft была настоящей неразберихой. Наряду со всей платформой .NET Framework, которая стала результатом того, что Microsoft по существу обратилась к чертежной доске о том, как выполнять продуктивное бизнес-программирование в стеке Windows, ASP.NET Web Forms в свое время была удивительной и красивой.

Весь подход состоял в том, чтобы дать разработчикам лучшее из обоих миров, что-то очень похожее на разработку приложений для Windows, но с мощью интернет-сервисов. Идея заключалась в том, что, как и в случае VB6 / WinForms "Форма" (окно), веб-страница также является формой (как окно, см.) , И на этой форме вы можете перетаскивать метки, текстовые поля, сетки данных, кнопки и другие вещи, к которым привыкли разработчики VB / WinForms GUI.

Чтобы заставить кнопку что-то сделать, после перетаскивания ее просто дважды щелкните по ней в конструкторе и загляните в редактор кода, сообщая форме, что делать, когда происходит это событие «щелчка». Именно так разработчики графического интерфейса Windows создавали программное обеспечение с использованием инструментов графического интерфейса VB6 и конкурирующих инструментов, за исключением того, что теперь код выполняется на сервере! Вау!

Это была технология 2002 года. Удивительный и красивый в то время ответ на решения с графическим интерфейсом для разработки RAD с поддержкой интернета , он привнес ощущение силы в грязный мир разработчиков программного обеспечения, у которого были бизнес-цели, которых им нужно было достичь.

К сожалению, эта модель программирования подчеркивает столько метафоры программирования Windows GUI, что несет с собой бремя необходимых деталей реализации, весь обременяющий багаж, необходимый для размещения жизненных циклов событий, и убрание уродливых деталей простого HTML и скрипт, который будут выводить эти компоненты и элементы управления перетаскиванием. И, в конце концов, разработчикам, поддерживающим реальные приложения, неизбежно приходилось копаться в этих компонентах или писать свои собственные, и, следовательно, они должны были сражаться с помощью этой инфраструктуры, сражений, которые оставляли бы кучу за кучей кучи, потянув за волосы, и слезы.

Резервный. Помой свои руки. Давайте снова посмотрим на бизнес-проблему. Каковы наши бизнес-цели?

Нам нужно создавать и управлять веб-приложениями . Наши ограничения заключаются в том, что у нас есть Всемирная паутина, которая работает на HTTP, HTML, Javascript и CSS, а на сервере у нас есть бизнес-правила, базы данных и небольшое количество отличных языков программирования (например, C #). Нужна ли нам эта метафора Windows GUI для управления нашей методологией разработки? Почему мы не можем просто сосредоточиться на проблемах приложения и покончить с метафорами графического интерфейса?

Именно здесь вступает ASP.NET MVC. Он начался с восстания разработчиков, которые называли себя «Alt.Net» и хотели вернуться к правильным и чистым принципам разработки программного обеспечения. Больше не нужно суетиться, просто сосредоточьтесь на бизнес-целях и лучших практиках программного обеспечения.

В данном случае это действительно означает:

1. Разделение проблем . Например, компонент данных не должен знать, как его данные будут отображаться, и разметка представления не должна быть обременена деталями конфигурации соединения с базой данных, и таким образом разработчик может сосредоточиться на своей проблемной области при редактировании и тестовый код.
2. Экспозиция и полная поддержка для ознакомления с мелочами HTML и связанных ресурсов . В веб-формах HTML спрятан, разработчики не советуются с этим возиться. В ASP.NET MVC разработчикам рекомендуется управлять этими деталями; на самом деле это необходимость. Преимущество в том, что разработчик может заново научиться ценить чистую семантику HTML, CSS и сценариев и работать с ними, а не против них.
3. Тестируемость бизнес-объектов . Контроллеры и модели намного лучше подходят для программного модульного тестирования, так что реализации могут быть проверены на соответствие бизнес-целям, а изменения могут быть проверены на предмет их поломки. С веб-формами было трудно тестировать, так как компоненты не были разработаны для индивидуального тестирования, а весь результат разработки вращался вокруг форм страниц и их жизненных циклов событий с густой взаимосвязью бизнес-логики и логики представления.

Обратите внимание, что HTML уже является языком разметки очень высокого уровня, а Javascript - языком программирования высокого уровня. Вся история была бы другой, если бы мы имели дело с языком ассемблера и C.

Далее, расширяя # 2, еще одна цель ASP.NET MVC - дать возможность разработчикам упорядочить детали интерфейса «части просмотра» своих решений и использовать богатую основу, на которой основывается остальная часть отрасли. платформа клиентского интерфейса.

Вы обнаружите, что разработчики ASP.NET MVC чувствуют себя как дома, используя богатые библиотеки Javascript и методы на стороне клиента, не борясь с архитектурой на стороне сервера. Первоначально это не имело место в ASP.NET Web Forms, потому что Web Forms вообще не хочет, чтобы вы смотрели на HTML или скрипт, кроме случаев, когда вам действительно нужно , и в этом случае будьте осторожны, это не для слабых сердца

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

Веб-формы
Используйте их, если у вас есть серьезные проблемы с сетками. Элементы управления сеткой действительно хороши, когда у вас есть простой набор данных, который отлично вписывается в табличный формат, и вы хотите предоставить пользователям простой способ обновления записей. Да, я знаю, что в MVC 4 есть действительно привлекательная вещь типа Ajax-списка, которую вы можете использовать, и это прекрасно работает, но в нашем бизнесе нам часто нужно что-то запустить вчера, и старые добрые гриды работают отлично, и пользователи рады быть возможность вкладывать по сетке с ликованием. Для меня это действительно лучшая вещь о WebForms для меня; но, как Райануказал на то, что WebForms может быть большим беспорядком, потому что вы играете по обе стороны от изящного файла с выделенным кодом. Это может быть как роза, так и шип одновременно, чтобы все ваши элементы типа контроллера были смешаны с вашими представлениями.

MVC
Используйте это, когда вы действительно хотите накатить свои собственные, и у вас есть возможность запустить приложение с нуля. Наличие четко определенного MVC-приложения - это немного больше работы, с которой нужно начинать, но его преимущества в удобстве обслуживания перевешивают первоначальную стоимость установки. Если вы хотите делать интересные Ajax-взаимодействия, предпочитаете писать свою модель с кодом, например, чистыми URL-адресами и маршрутами, и иметь возможность контролировать весь поток вашего приложения, тогда это определенно верный путь. Сначала нужно привыкнуть, но я думаю, что это лучший вариант для новых приложений.

В заключение, для меня это сводится к сеткам и! Сеткам. :)

Мой опыт:

• Писал проекты CakePHP на один год.
• Завершил проект Webforms среднего размера за шесть месяцев.
• Работал над проектом Windows Forms три года.

После этого опыта я попытался написать другое приложение, используя веб-формы, и был разочарован после того, как около дня боролся с тем, как веб-формы пытаются оградить разработчика от реальности того, что они разрабатывают приложение, использующее html, javascript и css.

Затем я попробовал MVC, и, имея более непосредственный контроль над выходом (и некоторый опыт работы с парадигмой MVC от CakePHP), я смог завершить это простое приложение именно так, как я хотел, примерно за 1/2 дня.

Наличие мощных структур пользовательского интерфейса, таких как jQuery, очень сильно избавляет от необходимости отказаться от прямого контроля над выходом в пользу использования часто громоздких предварительно созданных компонентов пользовательского интерфейса.

Я предпочитаю веб-формы, потому что мой фон - разработка окон.

Скорость разработки - ключевой вопрос, и я легко могу передать кому-то в Индии проблему, чтобы исправить в одночасье с помощью форм, а также, если у меня есть проблема со скоростью на странице, очень хорошая книга о скорости asp.net удобна (Рик Киссиг это мужчина).

Веб-формы для бывших людей Windows MVC для веб-людей

но в современном мире, где Рик написал потрясающую книгу, с ежедневным увеличением скорости серверов и дешевыми кодерами в Индии, веб-формы имеют преимущество

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

Я думаю, что абстрагирование от базового REST - это плохо, вся модель обратной передачи - плохо, то, как работает html / css с использованием GUI-редактора, плохо, упор на такие вещи, как мастера и графические интерфейсы для настройки, плох, URL-адреса плохие.

Я прочитал все ответы и чувствую, что мой личный опыт добавил бы что-то к ответам выше.

3-4 года назад я разработал 2-3 веб-проекта с использованием Webforms. В то время MVC не было рядом, или я не слышал об этом. Естественно, что разработка была для меня быстрой (я исходил из разработки Win-форм без предшествующего опыта веб-разработки), поскольку мне не нужно было подробно изучать HTML, а веб-элементы управления очень помогли (черт возьми, это облегчило жизнь) ,

Теперь, после всего этого времени, я до недавнего времени не работал ни с одним веб-проектом, а просто создавал приложение для Windows с использованием WPF.

Несколько дней назад у меня появилась идея для веб-сайта и я подумал о его разработке: на этот раз в MVC (поскольку о нем говорили повсюду, кроме того, мне нужно было либо учиться, поэтому я выбрал MVC). Проект все еще находится в стадии разработки, так как я все еще учусь и строю вместе.

Итак, ключевые различия, которые я нахожу ч / б, следующие: -

• Для тех, кто занимается разработкой Windows, веб-формы всегда будут выгодны. Кривая обучения Asp.net для разработчика Windows немного крута

• Для кого-то, кто занимается веб-разработкой по какой-то другой технологии, MVC будет предпочтительнее, поскольку он высмеивает последние из них.

• Разработка проще и понятнее в MVC, если вы хорошо знакомы с HTML и CSS

• Развертывание по-прежнему является проблемой. В веб-формах нужно просто скопировать и вставить. Но для этого нужно кое-что сделать.

Короче говоря, они оба останутся здесь на некоторое время.

Я еще не видел, чтобы это соображение выдвигалось среди существующих 15 ответов на эту ветку, но я думаю, что это стоит рассмотреть.

Из моего опыта Web Forms больше похожа на Win Forms и WPF, чем MVC. Учитывая это, я думаю, что можно было бы подумать о выборе веб-форм, когда команда обладает наибольшим опытом в такого рода технологиях, или когда проект веб-форм предоставит интерфейс для того же набора данных, что и существующие (или одновременно разработанные) Win Forms или Проект WPF. Это позволяет разработчикам легче переходить между проектами, поскольку логика приложения между ними может быть весьма схожей.

Как указывалось в других ответах, разработка на основе MVC больше похожа на веб-разработку на Ruby, PHP, Python и т. Д., Чем ее аналоги из Microsoft; поэтому, естественно, на выбор MVC может повлиять опыт команд в этих областях, а также факторы, представленные в других ответах.

Наша причина не ходить в MVC несколько лет назад в том, что это незрелая технология от Microsoft. За последние несколько лет мы находимся на более зрелой версии (4), и MS, кажется, разработала, куда они идут с этим. Тем не менее, мы по-прежнему не хотим разрабатывать основные LOB-приложения с использованием MVC, поскольку для функций, которые мы хотим использовать в версии 4, требуется сервер Windows 2012 (веб-сокеты через IIS8). Я рассчитываю, что еще через год мы будем больше принимать MVC, так как, надеюсь, будет доступно больше сторонних контролей, технология будет отлажена, и у нас будет инфраструктура для ее поддержки.

Это решение зависит от ваших предпочтений, ваших требований или даже ваших знаний и опыта.

Время для обучения обучения MVC или время, чтобы получить доставку. Все это важно, чтобы выбрать тот или иной подход.

Разве это не лучше, чем другое, просто и у подхода, и у рамок есть свои плюсы и минусы.

Лично я предпочитаю MVC 3, я рекомендую вам попробовать получить собственный опыт, но я должен сказать, что программа в MVC - это чистый, увлекательный, гибкий, расширяемый, безопасный и структурированный способ.

С Уважением,

Единственная причина, по которой я бы выбрал WebForms вместо MVC, заключается в том, что у вас гораздо больше сторонних элементов управления пользовательским интерфейсом для WebForms, чем MVC. Я выбираю MVC, потому что я слишком много работал с WebForms и хочу работать с чем-то свежим / новым, но все же из магазина MS :)

По сути, ничто не мешает вам отключить представление в WebForms и использовать ViewModels и циклы if / for вместо привязки модели и серверных элементов управления.

Это WebForms или код MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

Единственное ограничение, которое я обнаружил в WebForms, заключается в том, что если вы используете Dependency Injection / Inversion of Control, вы не можете использовать конструктор, так как на страницах WebForms должен быть конструктор без параметров, поэтому вы должны использовать инъекцию свойства. Это действительно такая большая сделка?

ASP.NET MVC действительно является ответом для Ruby, а также является новым, модным и (IMO) лучшим способом отсоединения браузера (клиента) от сервера в максимально возможной степени.

ASP.NET Webforms дает вам большой контроль над клиентом со стороны сервера, с прямым доступом практически ко всему. По сути, ваш взгляд и контроллер - это одно и то же, что дает вам много энергии и в большинстве случаев много беспорядка.

ASP.NET MVC разделяет представление и контроллер, отключая тесную связь файла .aspx и файла .aspx.cs, который сопровождает их в веб-формах.

По сути, разница заключается в том, что вы обрабатываете гораздо больше (как правило, всю) обработки для отображения данных в файле представления, а бизнес-логика и остальное остаются в контроллере, что делает их оба более чистыми по соглашению, но также с меньшим доступом к каждому кроме веб-форм позволяет.

На мой взгляд, они достаточно родственные и обладают примерно такими же возможностями, что и должны сводиться к предпочтениям.

Великий разработчик WebForms может создать такой же мощный продукт, как и великий разработчик MVC. Но великий разработчик WebForms, пытающийся заставить себя принять MVC, потерпит неудачу. То же самое относится и к великому разработчику MVC, который дает WebForms шанс.

Они не являются полностью отдельными объектами, и пока Microsoft продолжает поддерживать оба, я думаю, вы будете продолжать видеть смешанную группу исключительных разработчиков для каждого.

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

Недавно я использовал MVC для завершения проекта, и хотя мне очень нравится дизайн-подход к разработке приложений (который дает вам больше контроля, чистые URL-адреса, SOC и т. Д.), На самом деле он не так уж много предлагает, чего не могут сделать WebForms. Фактически, появление jQuery и его работы с WebForms (а также MVC) сделало эти аргументы менее значительными. И когда люди говорят о разделении интересов как о преимуществе, которое MVC имеет перед MVP, я спрашиваю их, как много они знают об объектно-ориентированном программировании и насколько они используют принцип абстракции и полиморфизма.

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

Когда я сталкиваюсь с проблемой программирования, я часто ищу ответы в Интернете. У Webforms есть тонны информации / компонентов, делающих что угодно. В MVC из-за меньшего количества онлайн-источников и слоев абстракций, необходимых для того, чтобы что-то работать, я ограничил свои возможности. Всего MVC убивает мою производительность как разработчика, а с Webforms это не так. Поэтому пока я придерживаюсь вебформ, пока MVC не станет достаточно зрелым, чтобы заменить его.

Что ж, в WebForms доступно больше учебных ресурсов (просто из-за того, что он старше), и поэтому новые программисты, которые «не в курсе», с большей вероятностью найдут информацию, касающуюся этой старой технологии, в отличие от более новых вещей, таких как MVC ,

Старшие / опытные программисты старше и будут более опытными в более старой технологии из-за того, что они программировали в ней дольше, чем в более новой.

Если вы не можете потратить деньги и усилия, чтобы ваши ребята были такими же опытными в MVC, как и в приложениях WebForms, вы, несомненно, постараетесь как можно дольше отложить обновление до новой платформы.

Таким образом, он представляет несколько логистических проблем: перевешивают ли преимущества MVC стоимость с точки зрения меньшего качества и времени развертывания? Если у меня есть сайт, полностью написанный на WebForms, стоило бы потратить усилия и деньги на интеграцию в него MVC?

Как было сказано предыдущим комментатором, MVC также не позволяет вам достичь того же уровня интерфейса с контроллером, который вы могли бы получить с помощью WebForms. Несмотря на то, что я целиком и полностью отношусь к принципу «не пускай пользователей в учебу / обучение», командам все еще может быть неоправданно хлопотно развертывать / реализовывать программу, которая фанатично придерживается этой парадигмы для всего, что они пишут.

Я думаю, что разрыв между этими двумя технологиями не так велик, как раньше.

• Веб-формы могут использовать механизм маршрутизации, который использует MVC (или что-то очень похожее).
• Диспетчер сценариев может объединять сценарии, загружать их из CDN и даже задерживать загрузку сценариев.

Чтобы прямо ответить на ваш вопрос, я думаю, что все сводится к предпочтениям и / или каков проект. Они оба используют совершенно разные подходы к развитию. Лично я работаю над переходом на MVC, но все еще люблю работать с Webforms. Я думаю, что ответ на вопрос о том, следует ли использовать MVC или Webforms, заключается в том, что вы сами решаете, используя обе технологии.