Веб-формы ASP.NET находятся под ковриком, чтобы освободить место для mvc?

Question

Я прочитал все маркетинговые статьи о том, как mvc и webforms дополняют друг друга и т.д. ...

Однако, похоже, что все блоги говорят о mvc, и единственная выходящая новость - о mvc.

Будет ли Microsoft продолжать УЛУЧШИТЬ веб-формы как первоклассный гражданин или это будет просто поддерживаемая технология, поскольку со временем все их реальные усилия, разработчики и ресурсы переносятся в mvc?

Существуют ли какие-либо реальные свидетельства каких-либо новых впечатляющих улучшений, которые появятся в веб-формах в ближайшем будущем?

Answer 1

Вы могли бы сделать хуже, чем взглянуть на пост Фила Хаака за ноябрь:

Будущее WebForms и ASP.NET MVC

Он указывает на 5 ключевых вещей, объявленных в рамках ASP.NET на PDC в прошлом году:

1. Базовая инфраструктура , включая масштаб и производительность
2. Веб-формы , включая проблемы с идентификаторами клиентов, ViewState, использованием CSS и т. Д.
3. AJAX
4. Данные и динамические данные
5. MVC

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

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

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

То же самое можно сказать о WPF / Silverlight - они убийцы WinForms / WebForms? Нет. Они являются альтернативными предложениями, с некоторыми преимуществами по сравнению с более ранним способом ведения дел, но также с некоторыми отличиями / недостатками.

Answer 2

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

Если вы сделаете шаг назад и просмотрите все последние улучшения и дополнения к стеку Microsoft, вы можете довольно легко классифицировать их между этими двумя классами. Например:

• Доступ к данным: LINQ-to-SQL против EntityFramework
• Remoting: WCF против веб-сервисов
• LiveID: LiveID (веб-аутентификация) против аутентификации RPS
• ...

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

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

Answer 3

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

MVC отлично! Но просто посмотрите на имя. Он обозначает «Модель, Вид, Контроллер» ... видите там «вид»?

Теперь посмотрите на конкурс "Веб-формы" ... видите "формы" в этом?

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

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

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

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

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

Answer 4

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

Модель веб-форм не исчезнет, ​​потому что:
Модель веб-форм лучше подходит для некоторых типов приложений, например небольшие приложения, требующие длительных процессов, в которых полезно использовать состояние просмотра
Многие приложения используют его
Для него разработано множество сторонних компонентов
Реализация ASP.net еще не созрела (хотя пока что выглядит довольно неплохо)

Microsoft, вероятно, объявит о ряде новых функций в PDC через несколько недель.

Answer 5

Прежде чем стало известно о среде MVC, мы потратили много времени на разработку собственной платформы .NET MVC моей компании.

Это произошло потому, что мы не хотели ограничиваться ограничениями абстракции WebForms - мы хотели избежать «неуклюжего» ощущения и компромиссов пользовательского интерфейса, которые WebForms, похоже, навязывают всем наиболее сильно настроенным приложениям. Кроме того, нам нужны были дружественные URI, и мы хотели лучше разделить внешнюю и внутреннюю разработку, чем те, которые предлагаются WebForms (мы остановились на архитектуре XML / XSLT).

По моему мнению, на самом деле WebForms предлагают гораздо более скудный метод взаимодействия с пользователем, в частности, из-за использования ViewState, PostBacks и т. Д., Которые абстрагируют реальную механику HTTP от разработчика - это дает им меньше свободы в том, как они позволяют пользователям взаимодействовать с системой. Классическим примером является то, что, поскольку страницы WebForms почти всегда являются результатом POST, если пользователь пытается обновить страницу, он получает неприятное предупреждение из браузера. Для решения этой проблемы в традиционном мире веб-разработки всегда было включение директивы 302 Redirect в HTTP-ответ, поэтому она придерживалась первоначальной парадигмы HTTP GET, предназначенной для извлечения данных, и POST, предназначенной для отправки данных. Существуют и другие подобные проблемы, такие как невозможность иметь две формы на странице (например, форму входа на веб-сайт на другом сервере).

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

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