Коли надавати перевагу ASP.NET WebForms над MVC

Я знаю, що Microsoft сказав

ASP.NET MVC не є заміною для WebForms.

А деякі розробники кажуть, що WebForms розвивається швидше, ніж MVC. Але я вважаю, що швидкість кодування знижується на рівні комфорту з технологією, тому я не хочу відповіді в цьому сенсі.

Зважаючи на те, що ASP.NET MVC надає розробнику більше контролю над їх застосуванням, чому WebForms не вважається застарілим? Крім того, коли я повинен надавати перевагу WebForms над MVC для нової розробки?

Веб-форми проти MVC, здається, зараз гаряча тема. Усі, кого я знаю, рекламують MVC, щоб стати наступною чудовою справою. З моїх незначних байдиків це здається нормальним, але ні, я не думаю, що це буде кінцем веб-форм.

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

Час / гроші - це найбільша причина, через яку веб-форми вибиратимуться через MVC.

Якщо більша частина вашої команди знає веб-форми, і у вас немає часу, щоб швидко переробити їх на MVC, код, який буде створений, може бути не якісним. Вивчення основ MVC, а потім стрибок у та складну сторінку, яку вам потрібно зробити, - це дуже різні речі. Крива навчання висока, тому потрібно враховувати це у своєму бюджеті.

Якщо у вас великий веб-сайт, написаний усіма веб-формами, можливо, ви будете більш схильні робити будь-які нові сторінки у веб-формах, щоб у вас не було двох дуже різних типів сторінок на вашому сайті.

Я не кажу, що це підхід все або нічого, але це робить ваш код важче підтримувати, якщо є розкол обох, особливо якщо не всі члени команди знайомі з MVC.

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

Нам потрібно було створити цілком нову структуру папок для цих сторінок, щоб вона відповідала правильному розділенню MVC.

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

На мою думку, ви б вибрали веб-форми через MVC, якщо у вас немає часу / грошей інвестувати в оновлення свого сайту для використання MVC. Якщо ви скористаєтеся напівзахисним підходом до цього, це не буде кращим, ніж веб-форми, які ви маєте зараз. Гірше, що ви навіть можете налаштувати цю технологію на провал у вашій компанії, якщо вона буде переплутана, оскільки вище керівництво може сприймати це як щось поступається тому, що вони знають.

Я розробляв додатки ASP .Net WebForms протягом 3 років, і після одного дня виконання підручника MVC мене продали. MVC майже ВЖЕ завжди краще рішення. Чому?

• Сторінка lifecylce простіша та ефективніша
• Окрім елементів керування html, таких елементів немає. Вам не потрібно налагоджувати вихід, щоб побачити, що ASP .Net генерує.
• ViewModels надають вам величезну силу і ухиляються від необхідності робити прив'язку вручну до керування, і це виключає багато помилок, пов’язаних із прив’язкою.
• Ви можете мати кілька форм на сторінці. Це було серйозним обмеженням WebForms.
• Інтернет є без громадянства, і MVC більше відповідає архітектурі Інтернету. Веб-форми представляють стан та помилки, які ви маєте з ним, вводячи 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. І, мабуть, найкваліфікованіший чоловік, який би відповів на це питання. Він був добрий, щоб відповісти:

"Різні клієнти шукають різних підходів до програмування, і багато люблять WebForms і вважають, що це чудово. Інші люблять MVC і вважають, що це чудово. Ось чому ми інвестуємо в обидва".

Отже, мені це говорить, що це не технічне питання. Це більше "м'яке питання", якщо ви хочете. Одне з особистих уподобань. Це відповідає тому, що кілька з вас сказали.

Дякую за всі відповіді.

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

Коротка відповідь:

• Використовуйте ASP.NET MVC, якщо ви плануєте належним чином створити веб-додаток із сучасними конвенціями програмування та прийнятими галузевими моделями для платформи ASP.NET. З нижньої сторони ви, як очікується, будете знати, як працюють HTML та клієнтські ресурси (Javascript, CSS), а також набігати на розумний настрій програмування MVC, який має круту криву навчання, але досягає раптового кінця після того, як це зрозуміло.
• Використовуйте веб-форми ASP.NET, якщо ви використовуєте або хочете використовувати GUI -центричний, RAD (швидкий розвиток додатків) , підтягування та підйом для прототипування чогось дуже швидко, тобто поведінку кнопки / сітки даних, підключеної в межах 15 хвилин, і рішення не має на меті підтримувати розробників. Або використовуйте веб-форми ASP.NET, якщо ви маєте досвід у розробці GUI або Windows Forms і хочете передати свої знання в Інтернет.

Але щоб правильно це подивитися, треба зрозуміти історію кожного.

ASP.NET Web Forms - це відповідь Microsoft тим, хто будував динамічні веб-програми за допомогою елементів керування Visual Basic 6 ActiveX, DLL VB6 на сервері та ASP Classic. У той час веб-розробка за допомогою цих інструментів Microsoft була справжньою безладдям. Поряд із всією сукупністю .NET Framework, яка була результатом Microsoft, по суті, повертаючись до креслярської дошки про те, як зробити продуктивне бізнес-програмування на стеку Windows, ASP.NET Web Forms був у свій час дивовижним і красивим.

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

Щоб змусити кнопку зробити щось, після перетягування та натискання на нього просто двічі клацніть по дизайнеру, і ви перебуваєте в редакторі коду, повідомляючи форму, що робити, коли трапляється ця подія "натискання". Саме так розробники Windows GUI створили програмне забезпечення за допомогою GUI- інструментів VB6 та конкуруючих інструментів, за винятком того, що код виконується на сервері! Оце Так!

Це була технологія 2002 року. Дивовижна і красива свого часу як відповідь на розроблені Інтернетом рішення GUI для розвитку RAD , вона принесла відчуття сили в безладному світі розробників програмного забезпечення, які мали бізнес-цілі, які їм потрібно було досягти.

На жаль, ця модель програмування настільки наголошує на метафорі програмування графічного інтерфейсу Windows, що вона несе з собою тягар її необхідних деталей щодо впровадження, весь обтяжливий багаж, необхідний для розміщення життєвих циклів подій та викреслення потворних деталей простого HTML та скрипт, який виводить ці перетягуючі компоненти та елементи керування. Зрештою, розробникам, які підтримують реальні програми, неминуче довелося заглибитися в ці компоненти або написати свої власні, і, отже, вони битимуться в битвах з цією інфраструктурою, битви якої залишатимуть за собою купи на кучах грубих, вирваних волосся та ін. сльози.

Резервне копіювання. Помий свої руки. Давайте ще раз розглянемо проблему бізнесу. Які наші бізнес-цілі?

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

Тут починається ASP.NET MVC. Це почалося повстанням розробників, які називали себе "Alt.Net", які хотіли повернутися до правильних і чистих принципів розробки програмного забезпечення. Більше не суєти і суєти, просто зосередьтеся на бізнес-цілях та найкращих практичних програм.

У цьому випадку це справді означає:

1. Розділення проблем . Наприклад, компонент даних не повинен знати, як його дані будуть надані, і не слід переглядати розмітку, обтяжену деталями конфігурації підключення до бази даних, і таким чином розробник може зосередитись на своїй проблематиці під час редагування та код тестування.
2. Експозиція та повна підтримка впливу стирчаної зернистості HTML та суміжних ресурсів . У веб-формах HTML витягується, розробники не бажають метушитися з цим. В ASP.NET MVC розробникам рекомендується керувати цими деталями; насправді це необхідність. Перевага тут полягає в тому, що розробник може знову навчитися цінувати чисту семантику HTML, CSS та скрипту та працювати з ним, а не проти цього.
3. Перевірка об’єктів бізнесу . Контролери та моделі набагато краще підходять для тестування програмних одиниць, так що реалізація може бути перевірена на відповідність бізнес-цілям, і зміни можуть бути перевірені, що вони не будуть порушені. З веб-формами було складно перевірити, оскільки компоненти не були розроблені для тестування індивідуально, і весь вихідний розвиток розгорнувся навколо форм сторінок та їх життєвих циклів подій із безліччю бізнес-логіки та логіки презентації, глибоко переплетених між собою.

Зауважте, що HTML - це вже дуже висока мова розмітки, як і Javascript - мова програмування високого рівня. Вся історія була б іншою, якби ми мали справу з мовою асамблеї та С.

Розширюючись на №2, тоді ще одна мета ASP.NET MVC полягає в тому, щоб дозволити розробникам організовувати детальну інформацію про частину "перегляду" своїх рішень та скористатися багатим фундаментом, на якому побудувала решта галузі. передня клієнтська платформа.

Ви побачите, що розробники ASP.NET MVC відчувають себе вдома, використовуючи багаті бібліотеки Javascript та методи шаблонування на стороні клієнта, не бореться з архітектурою на стороні сервера. Спочатку це не було з веб-формами ASP.NET, тому що веб-форми взагалі не хочуть, щоб ви дивилися на HTML чи скрипт, за винятком випадків, якщо вам справді потрібно , у цьому випадку остерігайтеся, це не для слабких людей. серця.

Я є повною та сумарною конвертацією в ASP.NET MVC і не озирнувся назад, тому сказав, що мені все одно доводиться підтримувати кілька дуже великих додатків WebForms. Ось мій погляд на це:

WebForms
Використовуйте ці, коли у вас є серйозні важкі підйоми, що стосуються сіток. Елементи керування сіткою дійсно дуже приємні, коли у вас є простий набір даних, який гарно вписується у табличний формат, і ви хочете надати простим способом оновлення записів для користувачів. Так, я знаю, що на MVC 4 є дійсно нескінченна річ типу Ajax, яку ви можете використовувати, яка чудово працює, але в нашому бізнесі нам часто потрібно щось вчора запустити, і хороші старомодні сітки працюють чудово, і користувачі раді вміє прошивати сітку з блиском. Для мене це справді найкраща річ у веб-формах; але, як Райанзазначив, що WebForms може бути великим безладом часу, оскільки ви граєте з обох сторін огорожі з чудового файлу з кодом. Це може бути як трояндою, так і шипом одночасно, щоб всі речі вашого типу контролера переплуталися з вашим переглядом.

MVC
Використовуйте це, коли ви дійсно хочете зробити свій власний і у вас є можливість запустити програму з нуля. Маючи чітко визначений додаток MVC - це трохи більше роботи, але його переваги в ремонтопридатності переважають від початкових витрат на налаштування. Якщо ви хочете робити цікаві взаємодії з Ajax, вважайте за краще писати свою модель з кодом, як-от чисті URL-адреси та маршрути, і зможете контролювати весь потік вашої програми, тоді це, безумовно, шлях. Спочатку потрібно звикнути, але я думаю, що це кращий варіант для greenfield-додатків.

На закінчення для мене це зводиться до сітки та! Сітки. :)

Мій досвід:

• Писали проекти CakePHP на один рік.
• Завершено проект веб-форм середнього розміру за півроку.
• Три роки працював над проектом Windows Forms.

Після цього досвіду я спробував написати інший додаток за допомогою веб-форм, і я засмутився, бо боровся близько дня з тим, як веб-форми намагаються захистити розробника від реальності, що вони розробляють додаток, що використовує html, javascript та css.

Потім я спробував MVC, і маючи більш прямий контроль над результатами (та деяким досвідом роботи з парадигмою MVC від CakePHP), я міг виконати цю просту програму саме так, як я цього хотів, приблизно за 1/2 дня.

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

Я вважаю за краще веб-форми, оскільки моїм фоном є розробка Windows.

Швидкість розвитку - ключове питання, і я можу легко передати проблему комусь в Індії, щоб виправити протягом ночі форми, також, якщо у мене є проблема швидкості на сторінці, дуже зручна книга про швидкість asp.net - це зручно (Рік Кіссіг - людина).

webforms for ex windows people mvc призначений для веб-людей

але в сучасному світі, де Рік написав дивовижну книгу, в якій сервери щодня збільшуються у швидкості та дешеві кодери в Індії, ну, веб-форми мають перевагу

Мої 2 копійки - завжди використовувати ASP.NET MVC для нових проектів, якщо у вас є можливість. На мою думку, веб-форми не є хорошим способом розробки веб-додатків, періоду.

Я думаю, що абстрагування основного REST - це погано, вся модель постбек - погана, спосіб передачі html / css з опорою на редактор графічного інтерфейсу поганий, акцент на такі речі, як майстри та графічні інтерфейси для налаштування матеріалів, поганий, 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. Зважаючи на це, я думаю, що можна подумати про вибір веб-форм, коли команда має найбільший досвід у галузі подібних технологій, або коли проект Web Forms доставить інтерфейс для того ж набору даних, що і існуючий (або одночасно розроблений) Win Forms або Проект WPF Це дозволяє розробникам переходити між проектами простіше, оскільки логіка програми може бути досить схожа між ними.

Як вказували інші відповіді, розробка в рамках MVC більше схожа на розробку веб-сторінок в Ruby, PHP, Python тощо, ніж на її колегах Microsoft; тому, природно, на вибір MVC може впливати досвід роботи команд у цих сферах, а також фактори, подані в інших відповідях.

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

Це рішення залежить від ваших уподобань, ваших потреб або навіть від ваших знань та досвіду.

Час для навчання навчанню MVC або час, щоб отримати доставку. Все це має значення для вибору того чи іншого підходу.

Чи не те, що один кращий за іншого, просто і підхід, і рамки мають плюси і мінуси.

Особисто я віддаю перевагу MVC 3, рекомендую спробувати отримати власний досвід, але мені потрібно сказати, що програма в MVC - це чистий, веселий, гнучкий, розширюваний, безпечний та структурований спосіб.

З повагою,

Єдина причина, чому я б обрав WebForms замість MVC, це те, що у вас є набагато більше сторонніх елементів управління інтерфейсом для WebForms, ніж MVC. Я вибираю MVC, тому що я занадто багато працював з WebForms і хочу працювати з чимось свіжим / новим, але все ж із MS shop :)

В основному, ніщо не заважає вам вимкнути вікно перегляду у WebForms та використовувати ViewModels та if / for циклів замість прив'язки моделі та керування стороною сервера.

Це веб-форми чи код MVC:

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

Єдине обмеження, яке я виявив у веб-формах, полягає в тому, що якщо ви використовуєте введення залежностей / інверсію управління, ви не можете вводити конструктор, оскільки на сторінках 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, я запитую їх, наскільки вони знають про об'єктно-орієнтоване програмування і наскільки вони вживають у використанні принцип абстракції та поліморфізму.

Наразі мені комфортно використовувати обидві технології, і я вибираю, виходячи із ситуації. Відверто кажучи, це залежить від вас, але правда залишається, що не кожен потребує свого часу, щоб глибоко дізнатися, на що здатна певна технологія.

Коли я стикаюся з проблемою програмування, я часто шукаю відповіді в Інтернеті. У веб-формах є безліч інформації / компонентів про те, щоб робити практично все, що завгодно. У MVC через меншу кількість джерел в Інтернеті та шари абстракцій, необхідних для того, щоб щось працювати, поставили межу в тих речах, які я колись міг би зробити. Загальний показник MVC вбиває мою продуктивність як розробника, тоді як для веб-форм це не так. Тому я зараз дотримуюся веб-форм, поки MVC не дозріє, щоб замінити її.

Ну, WebForms мають більше навчальних ресурсів (просто через те, що вона старша), і тому нові програмісти, які не знають, з більшою ймовірністю знайдуть інформацію про цю стару технологію на відміну від нових матеріалів, таких як MVC .

Старші / досвідчені програмісти старші і будуть більш досвідченими у старій технології завдяки тому, що вони програмували в ній довше, ніж у новій.

Якщо ви не зможете витратити гроші і зусилля, щоб ваші хлопці були досвідченими в MVC, як вони є в додатках WebForms, ви, безсумнівно, будете намагатися втриматися від модернізації до нової платформи як можна довше.

Отже, це представляє кілька логістичних проблем: Чи переваги MVC перевищують витрати з точки зору меншої якості та часу розгортання? Якщо у мене є сайт, повністю написаний у WebForms, чи варто докладати зусиль та грошей, щоб інтегрувати в нього MVC?

Як зазначав попередній коментатор, MVC також заважає вам досягти такого ж рівня інтерфейсу з контролером, як ви могли б з WebForms. Хоча я все за "Захистіть користувача від набивання речей / навчання" сторонам речей, це все ще може бути нерозумно клопітним для команд розгортання / реалізації програми, яка фанатично дотримується цієї парадигми для всього, що вони пишуть.

Я думаю, що розрив між цими двома технологіями не такий великий, як раніше.

• Веб-форми можуть використовувати механізм маршрутизації, який використовує MVC (або щось дуже подібне).
• Менеджер сценаріїв може комбінувати сценарії, завантажувати з CDN і навіть затримувати завантаження сценаріїв.

Щоб безпосередньо відповісти на ваше запитання, я думаю, що це зводиться до переваги та / або що таке проект. Вони обидва мають різний підхід до розвитку. Особисто я працював над тим, щоб рухатися до MVC, але все ще насолоджуюся роботою з веб-формами. Я думаю, що відповідь на те, що вам слід використовувати MVC або Webforms, - це ви вирішите через досвід обох технологій.