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

189

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

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

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

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

user53019
источник
57
@Darknight: \ это очень предвзято и просто неправильно. MVC не для простых приложений CRUD. Я бы сказал, что WebForms предназначены для универсальных приложений CRUD (например, база данных -> элемент управления блестящей сеткой).
Райнос
17
@Darknight - все, что делает тебя счастливым -> если тебе нравятся WebForms, сходи с ума от этого;)
Raynos
16
@ Darknight У вас явно плохое понимание MVC, если вы так думаете ... Есть несколько огромных сайтов, созданных с помощью mvc ... проведите небольшое исследование, сэр.
Робоцуши
31
ИМО, никогда не используйте веб-формы, когда вы можете вместо этого использовать MVC.
scottschulthess
10
Я не один, чтобы говорить, так что это только мое мнение. Прочитав большинство ответов, я пришел к выводу, что ответа просто нет. MVC просто потрясающий, и единственный недостаток, который я обнаружил, это то, что я продолжаю видеть ;на своей веб-странице (если вы только начинаете с Razor, вы получите шутку).
MasterMastic

Ответы:

105

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

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

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

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

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

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

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

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

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

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

Тианна
источник
14
Это хороший ответ. Я дал вам +1, потому что ваш личный опыт ценится. Но это провал из-за отсутствия опыта / навыков у разработчиков, которых я просил избегать. Я не уверен, что Microsoft предпочла бы не помечать устаревшую технологию просто из-за страха перед кривой обучения для MVC. Это может быть так, но я еще не убежден.
P.Brian.Mackey
6
@ P.Brian.Mackey - я не говорил, что разработка форм быстрее, чем MVC. Вы просили опустить этот аргумент. Спорить время и деньги на обучение персонала - это другой аргумент. MS не будет отмечать устаревание веб-форм по одной большой причине: корпоративные клиенты потратили годы на разработку веб-клиентов в веб-формах и не будут любезно тратить время и деньги на обновление.
Тианна
16
@Raynos - Если все в команде были опытными в MVC, и ваша компания начинала новый проект, то единственной причиной, по которой я мог видеть кого-то, выбирающего веб-формы, является личный выбор.
Тианна
3
Я хорошо знаю обе технологии. Все мои веб-проекты выполняются с помощью mvc, и я работаю в компании, где у меня есть свобода правления, и я делаю все, что лучше. Я всегда выбираю MVC.
Робоцуши
6
Я начал с Webforms и как только я обнаружил MVC, я переключился на это. Я не знаю, как кто-то может защищать веб-формы. Жизненный цикл страницы и одна форма для всей страницы? Ты шутишь, что ли? Yahoo sitebuilder был, вероятно, предназначенным клиентом для этого, но даже они не хотели этого барахла.
Маффин Ман
188

Я разрабатывал приложения 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, если проект уже не использует его.

Tjaart
источник
6
+1 за указание на несколько форм. Кроме того, тот факт, что веб-формы HTML генерируют, в большинстве случаев не очень оптимизирован для SEO (например, большие куски viewstate в верхней части страницы)
jao
4
Я должен согласиться на 100% с этим ответом. В конце концов, WebForms делает работу на стороне клиента (html / browser) намного сложнее. Вы буквально должны бороться с рамками, чтобы что-то сделать. Страница aspx заканчивается гораздо большим количеством кода из-за серверных элементов управления, чем обычно это делает страница cshtml. @ šljaker Если вы начинаете отключать ViewState и избегаете серверных элементов управления, на этом этапе вы отказались от большинства веб-форм. Я не считаю этот аргумент особенно убедительным.
Энди
12
Вы можете иметь простые HTML-элементы управления в WebForms, никто не заставляет вас использовать серверные элементы управления. Вы можете иметь полную Webform без сохранения состояния, никто не заставляет вас использовать ViewState. Вы можете использовать полный AJAX и JQuery в Webforms, никто не ограничивает вас от использования JQuery. Вы можете реализовать URL-маршрутизацию, никто не заставляет вас использовать статический файл базы URL. Рисование страницы вручную с помощью CSS отнимает столько времени, сколько требуется MVC. Вы можете создать HTML-страницу прямо в Webform.
mjb
5
@mjb: Если вы не используете серверные элементы управления, ViewState и т. д., зачем вообще использовать WebForms, когда MVC ближе к тому, что вы делаете? Это все равно что водить трактор на работу, но не делать внедорожных работ или использовать лопату / мотыгу или стабилизаторы поперечной устойчивости. В таком случае, почему бы просто не использовать машину?
Нельсон Ротермел
3
@Tjaart Это не совсем правильно, что вы не можете иметь несколько форм на странице ASPNET. У вас может быть столько форм, сколько вы хотите на странице ASPNET, но у вас может быть только одна форма сервера - форма с атрибутом runat = "server".
Кунцевич
80

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

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

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

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

Брайан. Маккей
источник
12
Скотт Гатри изобрел инфраструктуру MVC для ASP.NET во время полета из Лондона в Сиэтл в 2006-2007 годах. Если подумать, он тоже изобрел .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Называть его «экспертом» - огромное преуменьшение ;-)
Бенджамин Ховарт
27
Это хороший политический ответ от Скотта Гатри. Если бы он сам инвестировал свое собственное веб-приложение, вы бы увидели проект MVC, и для всего, что не могло быть сделано в MVC, Silverlight был бы запасным вариантом. Не воспринимайте это как отрицательный комментарий к WebForms, я думаю, что WebForms отлично подходят для внутренних приложений меньшего объема, которые могут использовать сторонние компоненты, такие как созданные Telerik. Я рад, что Microsoft продвигает обе технологии.
Шон Чейз
10
«Скотт Гатри изобрел MVC-фреймворк для ASP.NET во время полета». Я думаю, что это действительно упрощает MVC. Я не знаю Скотта Гатри, но готов поспорить, он какое-то время размышлял о том, как MVC может быть реализован в ASP.NET, и использовал этот долгий полет для реализации прототипа «голых костей» в качестве доказательства концепции.
Джон Макинтайр
6
«Вот почему мы инвестируем в оба». И когда мы увидим, что веб-формы начинают сокращаться, мы беспощадно отбрасываем их, потому что инвестирование в конечный мертвый продукт не отвечает нашим деловым интересам.
затруднение
Пока его больше не преподают в школах, в течение многих лет он всегда будет применяться в деловом мире. Колледжи и средние школы продолжают предлагать интро и продвинутые курсы в vb.net. Это никуда не денется !!!
htm11h
44

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

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

  • Используйте 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 или скрипт, кроме случаев, когда вам действительно нужно , и в этом случае будьте осторожны, это не для слабых сердца

stimpy77
источник
Это хороший ответ, но # 1 и # 2 неверны (WF не требует, чтобы компонент знал, откуда берутся его данные, это опция, и вы всегда добавляли HTML в свои файлы ASPX для поддержки используемых вами тегов asp рендеринг. Вам никогда не нужно было углубляться и бороться с элементами управления, если вы не пытались получить доступ к функции ASP, не предназначенной для взаимодействия с разработчиками. Важными моментами являются тестируемость и шаблон проектирования.)
Trisped
39

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

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

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

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

Nodey The Node Guy
источник
+1 за красивую картинку, поставленную с «игрой с обеих сторон забора из отличного файла с выделенным кодом».
Марсель
Очень полезно это. Я делаю очень тяжелое приложение, основанное на сетке, и я исключил silverlight, xbap, и это было шоу между этими двумя.
морозно,
15

Мой опыт:

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

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

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

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

mootinator
источник
2
@JimG - Э-э, все, что включает в себя человека, который вводит записи без интересных ассоциаций в базу данных и заставляет этого человека или кого-то еще читать / распечатывать их в какой-то другой точке, может быть в основном защищено с помощью инфраструктуры MVC. Конечно, это не большинство приложений, но это намного больше, чем вы можете сделать с помощью форм. Я думаю, что ваш -1 доказывает мою точку зрения.
mootinator
1
Это 1/4 дня.
mootinator
1
Но если требования равны: «Мне нужно приложение с двумя ролями: одно для записи некоторой информации, другое для ее просмотра, и мне все равно, как оно выглядит». Тогда да, это вполне выполнимо.
mootinator
3
извините, но разработка приложения для веб-форм для ввода и просмотра данных настолько проста, что сделать это можно за несколько часов. создание структуры приложения MVC, Controllers, Views и Actions, заняло бы столько же времени, но не дало бы вам готового продукта.
Дементик
2
@Dementic Обычно для простого приложения MVC создаются модели, а затем создаются контроллеры и представления и / или генерируются строительные контроллеры / представления. Ничего особо трудоемкого там нет.
mootinator
8

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

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

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

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

Джейсон Палмер
источник
7

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

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

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

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

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

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

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

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

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

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

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

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

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

Панкадж Упадхяй
источник
6

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

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

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

Энди Хант
источник
+1 Конечно разумный аргумент для вебформ. Я боюсь, что команды следуют этому образу мышления, чтобы избежать изучения новых вещей. MVC наполнен множеством шаблонов, которые могут быть незнакомы команде. Изучение этих типов шаблонов и их реализация приводит к лучшему соблюдению принципов SOLID, что приводит к улучшению общей ремонтопригодности. Эти проверенные методы являются также реальным ключом к повторному использованию.
P.Brian.Mackey
3

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

Стив
источник
1
Не могли бы вы перечислить некоторые из этих функций, требующих Windows Server 2012?
MikeTeeVee
2

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

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

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

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

С Уважением,

оборота пакоэспиноза
источник
2

Единственная причина, по которой я бы выбрал 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 должен быть конструктор без параметров, поэтому вы должны использовать инъекцию свойства. Это действительно такая большая сделка?

šljaker
источник
1

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

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

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

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

Райан Хейс
источник
Итак, КОГДА следует отдавать предпочтение веб-формам по сравнению с MVC? Это не отвечает на вопрос оригинальных постеров.
Стивен Стрига
@WeekendWarrior - когда вы хотите получить больший доступ к клиенту на стороне сервера, выбирайте веб-формы. Если вы хотите больше отделить клиент / сервер в вашем коде, выберите MVC. В конце дня они оба делают одно и то же. Фильтры перенаправления выполняют те же действия, что и URL-адреса MVC, и вы можете переместить код веб-форм на отдельный средний уровень, чтобы еще больше его отделить. weblogs.asp.net/scottgu/archive/2010/01/24/…
Райан Хейс
Что касается вашего третьего пункта, эта бизнес-логика заканчивается в файле .aspx.cs - я думаю, что это вина разработчиков. Это не / предполагается / быть там. В веб-формах .aspx - это «представление», а .aspx.cs - это эквивалент «контроллера», предназначенный для обработки кода, который напрямую связан только с пользовательским интерфейсом, путем опроса бизнес-уровня или грубого уровня бизнес-фасада. Тот факт, что люди помещают бизнес-логику в .aspx.cs, просто плохое программирование. Они также могут поставить бизнес-логику прямо в поле зрения в MVC! MVC не заставляет разделять эти вещи.
Джеймс
По сути он более прав, чем другие ответы, опубликованные здесь. ASP.net - основная идея семейства модульных веб-технологий, созданного Microsoft. Модуль ASP.net MVC может быть временным обманом, но наверняка он не последний, все начинается с ASP.net, поэтому, когда вы выбираете ASP.net, если вы не думаете, что MVC - это не ваша вещь, возможно, вам больше нравится что-то иначе OWIN или ..., что-то более продвинутое, или сделайте вашу собственную структуру для ваших задач. Вам может даже не понадобиться ASP.MVC, пропустить его и перейти к Оуэну или Катане, но пока вы там не используете asp.net
user3800527
1

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

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

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

user29981
источник
0

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

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

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

Дэвид Грант
источник
То же самое относится к огромным возможностям веб-форм. Большинство людей видят учебные колеса веб-форм и сравнивают это с MVC.
TheLegendaryCopyCoder
Нет смысла изучать абстракции поверх HTML и Javascript в наши дни (даже в 2013 году). Это не принесет вам пользы для ваших будущих возможностей. HTML и Javascript прекрасно работают так, как есть. Борьба с ним - проигрышная битва.
user441521
0

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

Сынок
источник
0

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

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

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

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

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

user32288
источник
-1

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

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

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

Маффин Человек
источник
1
По умолчанию Webforms и MVC рекомендуют принципиально иной подход к веб-разработке, это важно , лишь немногие разработчики отклоняются от «по умолчанию». Оба они могут быть использованы для достижения одного и того же.
Райнос