Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

MVC отлично! Но просто взгляните на имя. Это означает "Model, View, Controller"... см. "Вид" там?

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

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

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

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

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

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

Ответ 5

До начала распространения рамок MVC мы потратили много времени на то, чтобы моя компания разработала собственную инфраструктуру .NET MVC.

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

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

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

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