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

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

Будущее веб-форм и ASP.NET MVC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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