Самое большое преимущество использования ASP.Net MVC против веб-форм

164

Каковы некоторые из преимуществ использования одного над другим?

user18931
источник

Ответы:

165

Основными преимуществами ASP.net MVC являются:

  1. Включает полный контроль над отображаемым HTML.

  2. Обеспечивает чистое разделение проблем (SoC).

  3. Включает разработку через тестирование (TDD) .

  4. Простая интеграция с фреймворками JavaScript.

  5. Следуя дизайну безликого характера сети.

  6. RESTful URL, которые позволяют SEO.

  7. Нет событий ViewState и PostBack

Основным преимуществом веб-формы ASP.net являются:

  1. Обеспечивает разработку RAD

  2. Простая модель разработки для разработчиков, пришедших от разработки winform.

резюме
источник
32
Что касается SoC, люди могут испортить его так же, как и в веб-формах, написав «толстые» контроллеры с большим количеством бизнес-логики или даже кода доступа к данным. Так что я бы сказал, что SoC - это то, что должно быть предоставлено кодером, fw не может помочь.
rodbv 12.12.08
7
@ rodbv: Очень верно, но MVC как бы подталкивает вас в правильном направлении, или, по крайней мере, не заставляет вас прыгать через обручи, чтобы сделать это. Так что, возможно, этот пункт должен читаться как «облегчает реализацию SoC»
Эрик ван Бракел
4
Как это «Включить разработку через тестирование» по сравнению с любым другим методом? Я также запутался, как он разрешает URL-адреса RESTful, когда метод HttpContext.RewritePath (String) существует с .NET 2.0?
Марк Бродхерст
2
Хотя эти пункты в основном точны для MVC, многие из них уже интегрированы в WebForms.
rtpHarry
Ссылка на источник этого ответа с более подробной информацией: weblogs.asp.net/shijuvarghese/archive/2008/07/09/…
DK.
91

ASP.NET Web Forms и MVC - это две веб-среды, разработанные Microsoft - оба они являются хорошим выбором. Ни одна из веб-фреймворков не должна быть заменена другой, и не планируется их объединение в единую фреймворк. Непрерывная поддержка и развитие выполняются Microsoft параллельно, и ни один из них не исчезнет.

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

Веб-формы ASP.NET:

  • Состояние поддержки разработки • Создает иллюзию, что веб-приложение знает о том, что делал пользователь, подобно приложениям Windows. Т.е. функциональность «мастера» становится немного проще в реализации. Веб-формы делают большую работу, скрывая большую часть этой сложности от разработчика.
  • Быстрая разработка приложений (RAD) • Возможность просто «прыгнуть» и начать предоставлять веб-формы. Это оспаривается некоторыми из сообщества MVC, но подталкивается Microsoft. В конце концов, все сводится к уровню знаний разработчика и тому, что ему удобно. Модель веб-форм, вероятно, имеет меньшую кривую обучения для менее опытных разработчиков.
  • Увеличенный набор инструментов управления • ASP.NET Web Forms предлагает гораздо больший и более надежный набор инструментов (веб-элементы управления), тогда как MVC предлагает более примитивный набор элементов управления, опирающийся больше на богатые клиентские элементы управления через jQuery (Javascript).
  • Зрелые • Это существует с 2002 года, и существует множество информации о вопросах, проблемах и т. Д. Предлагает больше стороннего контроля - необходимо учитывать ваши существующие наборы инструментов.

ASP.NET MVC:

  • Разделение задач (SoC) • С технической точки зрения организация кода в MVC очень чистая, организованная и детальная, что упрощает (надеюсь) масштабирование веб-приложения с точки зрения функциональности. Продвигает отличный дизайн с точки зрения разработки.
  • Более простая интеграция с инструментами на стороне клиента (богатые инструменты пользовательского интерфейса) • Веб-приложения, как никогда ранее, становятся все более богатыми, чем приложения, которые вы видите на своих рабочих столах. MVC дает вам возможность более легко и легко интегрироваться с такими наборами инструментов (например, jQuery), чем в веб-формы.
  • Поисковая оптимизация (SEO), дружественные / не имеющие состояния • URL-адреса более удобны для поисковых систем (например, mywebapplication.com/users/ 1 - получить пользователя с идентификатором 1 против mywebapplication / users / getuser.aspx (идентификатор передан в сеансе)). Точно так же, поскольку MVC не имеет состояния, это устраняет головную боль пользователей, которые порождают несколько веб-браузеров из одного окна (коллизии сеансов). В том же духе MVC придерживается веб-протокола без сохранения состояния, а не борется с ним.
  • Хорошо работает с разработчиками, которым требуется высокая степень контроля. • Многие элементы управления в веб-формах ASP.NET автоматически генерируют большую часть необработанного HTML-кода, который вы видите при визуализации страницы. Это может вызвать головную боль для разработчиков. С MVC он лучше подходит для полного контроля над тем, что визуализируется, и никаких сюрпризов. Еще более важно то, что HTML-формы, как правило, намного меньше веб-форм, что может означать повышение производительности - что-то, что стоит серьезно рассмотреть.
  • Разработка через тестирование (TDD) • С MVC вы можете легче создавать тесты для веб-приложений. Дополнительный уровень тестирования обеспечит еще один уровень защиты от неожиданного поведения.

Аутентификация, авторизация, конфигурация, компиляция и развертывание - все это функции, которые совместно используются двумя веб-платформами.

JC
источник
27
«С MVC вы получаете полный контроль над тем, что отображается» - вы также можете иметь полный контроль над WebForms, если вы используете литералы вместо меток, заполнители вместо панелей, повторители вместо блоков данных и т. Д. Слишком много разработчиков читают такие утверждения и верю, что это правда.
Downvote
3
@masty - я не знаю, что лично я бы понизил голос, но я согласен с остальным, что вы сказали.
Питер
4
@masty - Спасибо за спасение мира StackOverflow, придираясь и прося, чтобы этот вопрос был опущен. Я отредактировал свой ответ только для вас - так что, надеюсь, я смогу вернуть ваш голос вместе со всеми остальными, что вы попросили понизить его. Спасибо!
JC
6
@masty Я согласен частично, но при использовании литералов, заполнителей и повторителей вы все больше и больше перемещаете html в код. Что также может вызвать путаницу у дизайнеров, читающих .aspx, и у кодеров, читающих .aspx.cs. Так что да, это возможно, но да, это также отрицает цель ASP.Net WebForms. Я бы сказал, что ControlAdapters - более чистое решение в этом случае. Вместо замены элементов управления вы заменяете способ их визуализации.
Aidiakapi
2
Утверждение «С MVC вы имеете полный контроль над тем, что отображается», запутано. Я думаю, что лучшим утверждением было бы: «Платформа MVC делает меньше рендеринга, а то, что рендерится, является более гибким. Вам предоставляется больший контроль над конкретным HTML / CSS, который рендерится, но вы должны выполнить работу, чтобы получить этот контроль».
кингданго
17

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

Когда появился ASP.Net, он был провозглашен спасителем, отделяющим код от контента и позволяющим веб-дизайнерам создавать html, а кодеры - работать над кодом. Если мы не хотели использовать ViewState, мы отключили его. Если по какой-то причине мы не хотим использовать код позади, мы можем поместить наш код в html, как классический ASP. Если мы не хотим использовать PostBack, мы перенаправляемся на другую страницу для обработки. Если мы не хотели использовать элементы управления ASP.Net, мы использовали стандартные элементы управления HTML. Мы могли бы даже опросить объект Response, если бы не хотели использовать ASP.Net runat = "server" в наших элементах управления.

Теперь кто-то в своей большой мудрости (возможно, кто-то, кто никогда не программировал классический ASP) решил, что пришло время вернуться к временам смешивания кода с контентом и назвать это «разделением интересов». Конечно, вы можете создать более чистый HTML, но вы могли бы с классическим ASP. Сказать «вы не программируете правильно, если у вас слишком много кода внутри вашего представления» - все равно, что сказать «если вы написали хорошо структурированный и прокомментированный код в классическом ASP, это намного чище и лучше, чем ASP.NET»

Если бы я хотел вернуться к смешиванию кода с контентом, я бы посмотрел на разработку с использованием PHP, который имеет гораздо более зрелую среду для такого рода разработки. Если есть так много проблем с ASP.NET, то почему бы не исправить эти проблемы?

И последнее, но не менее важное: новый движок Razor означает, что еще сложнее отличить HTML от кода. По крайней мере, мы могли бы искать открывающие и закрывающие теги, т.е. <% и%> в ASP, но теперь единственным указанием будет символ @.

Возможно, пришло время перейти на PHP и подождать еще 10 лет, чтобы кто-то снова отделил код от контента.

Кевин Фарроу
источник
7
+1 Спот на. Моей первой реакцией на MVC было то, что я снова делал Classic ASP; только в C # на этот раз вместо VBScript.
Танцы с бамбуком
3
Я поражен, почему этот ответ получил так много голосов. Во-первых, в ASP.NET MVC встроено разделение MVC. Конечно, вы можете сделать это в ASP. Во-вторых, ASP.NET MVC - это гораздо больше, чем классический ASP. Он предлагает детальный контроль над HTML в сочетании с мощью .NET в сопровождении множества полезных помощников. В-третьих, @ - это хорошее обозначение, как и <%%>. Любой достойный редактор для ваших просмотров Razor будет поддерживать @ -notation. Наконец, зрелый PHP? me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design ASP.NET MVC - отличная платформа. Дайте этому больше внимания.
JP Ten Berge
Ты шутишь, что ли? Я использую PHP с нотацией «<? ...?>» И обнаружил, что он очень многословен. Я не понимаю, как символ "@" сложнее распознать, чем теги "<% ...%>". Кроме того, вы редко используете символ «@» в шаблонах HTML.
Exegesis
Мои глаза могут действительно лучше отдыхать на странице бритвы, чем в аду символов "<%%>". Чтение страницы .aspx вызывает у меня головную боль. Я также предпочитаю видеть, что делается. Блок @foreach (..) {<tr> ... </ tr>} позволяет мне чувствовать себя более комфортно, чем <abc: MyViewControl ID = "..." runat = "server" DatasourceID = ".... "/>. Я делаю много манипуляций на стороне клиента, и мне нужно точно знать, что будет отображаться, где и с каким идентификатором, стилем и классами. Я предпочитаю делать это сам, чем позволить контролю делать это на лету. Особенно, когда некоторые элементы управления отображаются по-разному в зависимости от их настроек.
Танасис Иоаннидис
Я удивлен, что у этого есть положительные отзывы, это полное недопонимание структуры MVC. Если вы обнаружите, что смешиваете код с содержимым в MVC, вы делаете это неправильно. Ваши представления имеют контент, ваши контроллеры (и используемые ими классы) имеют код. Это один из основных принципов MVC.
Джош Ноу
14

Если вы работаете с другими разработчиками, такими как PHP или JSP (и я предполагаю, что это рельсы) - вам будет намного проще конвертировать или сотрудничать на страницах, потому что у вас не будет всех этих «грязных» ASP.NET события и элементы управления везде.

Simon_Weaver
источник
"намного легче время", используя какой?
Cregox
5
@cawas - намного проще с MVC. в ASP.NET MVC нет событий. в основном вы имеете дело со стандартным HTML и CSS, а не с большим количеством событий и элементов управления, которые разработчики PHP / JSP должны были бы изучить
Simon_Weaver
ASP.NET является базой для веб-форм и MVC. Люди склонны путать веб-формы с ASP.NET. Там нет "MVC против ASP.NET". Существует «ASP.NET MVS» против «ASP.NET WebForms». И на самом деле они не сражаются друг с другом. Это просто разные способы с разными плюсами и минусами, для создания сайта
Thanasis Ioannidis
13

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

Merc
источник
1
+1 для бизнеса определяется основной вещью «Быстрое решение, которое работает»
Драгос Дурлут
1
Проблема в том, что некоторые быстрые решения просто не работают, потому что они изначально были быстрыми. Недавний опыт: быстрая страница веб-форм, чтобы сделать некоторые основные create-edit-update. Предполагалось, что он будет «быстрее», чем страница Infopath Equiveland, которая была немного медленной. На самом деле, новое решение имело почти такую ​​же производительность со страницей infopath, за исключением IE7, где оно было крайне медленным до такой степени, что стало бесполезным. 5 секунд, чтобы открыть страницу, и 5 секунд каждый раз, когда щелкали по списку ... Все это только потому, что оно должно было быть быстрым. Без мыслей, без планирования.
Танасис Иоаннидис
1
После этого мы в итоге удалили все элементы управления, чтобы избавиться от их тяжелых и ненужных сценариев на стороне клиента, и закончили рендерингом ручных элементов управления html с загруженными данными и событиями, а также комбинацией jQuery и BackBone.js. Это на самом деле подход MVC, размещенный на странице веб-форм. Конечно, при хорошем планировании WebForms и MVC могут работать очень хорошо, но WebForms побуждает вас просто бросить элементы управления на своей странице, просто чтобы увидеть, как что-то движется на вашем экране, и затем вы тратите больше времени на его настройку, если не удаляете его. вообще.
Танасис Иоаннидис
11
  1. Правильный AJAX, например, JSONResults без частичной ерунды обратной передачи страницы.
  2. нет просмотра +1
  3. Нет переименования идентификаторов HTML.
  4. Чистый HTML = без раздумий и с приличным умением отрисовывать страницы, соответствующие XHTML или стандартам.
  5. Больше не генерируется AXD Javascript.
Фрэнсис Шанахан
источник
9

Самым большим преимуществом для меня было бы четкое разделение между вашими слоями Model, View и Controller. Это помогает продвигать хороший дизайн с самого начала.

Мэтью Растон
источник
4
Я согласен, что это главное преимущество, если вы никогда раньше не работали с этим типом шаблона, но вы можете реализовать свой шаблон MVC или MVP в WebForms. Престижность за то, что они заставляют людей переходить к шаблону, а не монолитизировать веб-форму с наборами данных, но они не из тех людей, которых я обычно нанимаю.
Марк Бродхерст
9

Я не видел никаких преимуществ в MVC по сравнению с ASP.Net. 10 лет назад Microsoft придумала UIP (User Interface Process) в качестве ответа MVC. Это был провал. Мы тогда делали большой проект (4 разработчика, 2 дизайнера, 1 тестер) с UIP, и это был настоящий кошмар.

Не просто прыгнуть в подножку ради обмана. Все перечисленные выше преимущества уже доступны в Asp.Net (с более замечательными настройками [ Новые функции в Asp.Net 4 ] в Asp.Net 4).

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

Криш Ван Коломбо
источник
1
Отключение viewstate по умолчанию при включении его на случайном элементе управления, который действительно нуждается в нем, было большим шагом вперед в ASP.NET 4.
PeteT
И WebForms, и MVC построены на основе ASP.NET.
Танасис Иоаннидис
8

Фрэнсис Шанахан,

  1. Почему вы называете частичную обратную передачу "чепухой"? Это основная особенность Ajax, и она очень хорошо использовалась в инфраструктуре Atlas и замечательных сторонних элементах управления, таких как Telerik.

  2. Я согласен с вашей точкой зрения относительно состояния. Но если разработчики осторожны, чтобы отключить viewstate, это может значительно уменьшить размер HTML-кода, который отображается, таким образом, страница становится легче.

  3. Только элементы управления HTML-сервера переименовываются в модель веб-формы ASP.NET, а не чисто HTML-элементы управления. Как бы то ни было, почему вы так волнуетесь, если переименование сделано? Я знаю, что вы хотите иметь дело со многими событиями javascript на стороне клиента, но если вы будете грамотно разрабатывать свои веб-страницы, вы определенно сможете получить все идентификаторы, которые хотите

  4. Даже ASP.NET Web Forms соответствует стандартам XHTML, и я не вижу вздутия. Это не оправдание того, почему нам нужен шаблон MVC

  5. Опять же, почему вы обеспокоены AXD Javascript? Почему тебе больно? Это снова не обоснованное оправдание

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

Самый большой недостаток MVC - мы возвращаемся ко временам ASP. Помните код спагетти смешивания кода сервера и HTML ??? Боже мой, попробуйте прочитать страницу aspx MVC, смешанную с javascript, HTML, JQuery, CSS, тегами сервера и прочее. Любое тело может ответить на этот вопрос?

Ganesh
источник
6
Частичные
обратные
3
Если в ваших представлениях много кода, значит, вы делаете что-то не так. Код в представлениях должен касаться только макета.
UpTheCreek,
1
Единственная причина, по которой вы видите страницу с javascript, смешанным с css и html, заключается в том, что вы смотрите на работу ленивого разработчика, который не может быть обеспокоен разделением стилей и скриптов. Это может произойти в веб-формах и MVC. Я согласен с тем, что теги скриптов некрасивые, но с MVC3 они точно больше не существуют, и, по крайней мере, вы можете увидеть, что происходит, не заглядывая в код за файлом и не находя точку, где элемент управления привязан к данным ...
jcvandan
Также, если вы создаете код спагетти с использованием MVC, вы не придерживаетесь принципа разделения интересов и не используете хорошую архитектурную модель
jcvandan
1
Используя оба, я могу сказать, что ничто не становится более грязным, чем WebForms. MVC чист, за исключением тегов сервера, но, кроме того, весь беспорядок - ошибка плохих программистов. MVC разработан ядром, чтобы отделить логику от дизайна. Также вы упоминаете Telerik. Telerik для ASP.Net AJAX вызывает такой грязный код. Не говоря уже о скорости, (перемешивание) сортировки телерик сетки занимает: 500 мс для 4 страниц в ASP.Net WebForms, занимает 200 мс для 84 страниц в MVC. (Протестировано с использованием их демоверсии и Firebug для Chrome.) Когда дело доходит до производительности и разделения, MVC определенно побеждает.
Aidiakapi
6

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

Timbo
источник
2
Не сказать, что это невозможно сделать с помощью MVC, потому что я уверен, что это так, но если вы хотите соединить быстрое и грязное приложение для интрасети или экстрасети с большим количеством смешанных Telerik и WebForms, сложно победить. Пламя прочь, это чистая правда.
инфоцид
У Telerik также есть элементы управления MVC (меньше и с меньшим количеством опций, но, тем не менее, они есть), и они НАМНОГО быстрее, чем их варианты WebForm.
Aidiakapi
5

В веб-формах вы также можете визуализировать практически весь html вручную, за исключением нескольких тегов, таких как viewstate, eventvalidation и аналогичных, которые можно удалить с помощью PageAdapters. Никто не заставляет вас использовать GridView или какой-либо другой серверный элемент управления с плохим выводом HTML-рендеринга.

Я бы сказал, что самое большое преимущество MVC - это СКОРОСТЬ!

Следующим является принудительное разделение интересов. Но это не запрещает вам помещать целую логику BL и DAL в контроллер / действие! Это просто разделение вида, что можно сделать и в веб-формах (например, шаблон MVP). Многие вещи, которые люди упоминают о mvc, могут быть сделаны в веб-формах, но с некоторыми дополнительными усилиями.
Основное отличие состоит в том, что запрос поступает в контроллер, а не в представление, и эти два слоя разделены, а не связаны через частичный класс, как в веб-формах (aspx + код позади)

Hrvoje Hudo
источник
Вы имеете в виду скорость разработки или скорость выполнения?
Жюль
1
Особенно при использовании телерика с MVC. Из их демонстрации сортировка сетки занимает: 500 мс для 4 страниц (WebForms), 200 мс для 84 страниц (MVC). Что для меня предпочтение MVC (даже несмотря на то, что мы используем WebForms в моей компании, хотя мы думаем о том, чтобы сделать переход), так это то, что он чище, у вас есть ваши взгляды, где вы адаптируете свой вывод, свою модель, где вы путаетесь до данных: P, и ваши контроллеры, которые собрали все это вместе
Aidiakapi
4

Мои 2 цента:

  • ASP.net формы отлично подходит для быстрой разработки приложений и быстрого увеличения стоимости бизнеса. Я все еще использую это для большинства приложений интранета.
  • MVC отлично подходит для поисковой оптимизации, так как вы в большей степени контролируете URL и HTML
  • MVC, как правило, создает намного более простую страницу - нет состояния просмотра и более чистый HTML = быстрое время загрузки
  • MVC легко кешировать части страницы. -МВК интересно написать: - личное мнение ;-)
Николас
источник
3

MVC позволяет иметь более одной формы на странице, небольшая функция, которую я знаю, но она удобна!

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

миндальный
источник
2
ASP.NET Webforms позволяет вам иметь столько форм на странице, сколько вы хотите. Ограничение состоит в том, что только один может иметь атрибут «runat =» server »
Андрей Рина
1
@AndreiRinea Я думаю, он имел в виду следующее: P, runat="server"тэг без формы не очень полезен, когда вы все еще хотите использовать веб-формы, и, поскольку вы не можете / не должны вкладывать формы, я думаю, что это довольно очевидно, что он имел в виду :)
Aidiakapi
2

Контроллер MVC:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

MVC View:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

Насколько это сложно? No ViewState, No BS Page жизненный цикл ... Просто чистый эффективный код.

Джейсон
источник
1

Я вижу только два преимущества для небольших сайтов: 6) RESTful URL, которые позволяют SEO. 7) Нет событий ViewState и PostBack (и вообще более высокая производительность)

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

Я отчетливо вижу преимущество MVC на крупных сайтах для разработчиков.

Род Рай
источник
1

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

Webforms и MVC являются жизнеспособными инструментами, оба превосходны в разных областях.

Я лично использую веб-формы, так как мы в основном разрабатываем приложения B2B / LOB. Но мы всегда делаем это с помощью паттерна MVP, с помощью которого мы можем достичь 95 +% покрытия кода для наших модульных тестов. Это также позволяет нам автоматизировать тестирование свойств webcontrols. Значение свойства отображается в представлении, например:

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

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

En.
источник
0

Вы больше не чувствуете себя плохо, когда используете «не-постбэк контроль» - и пытаетесь понять, как заглушить их в традиционной среде asp.net.

Это означает, что современные (бесплатные в использовании) элементы управления javascript, такие как этот или этот или этот, могут быть использованы без попытки подгонки круглого колышка в форме квадратного отверстия.

Simon_Weaver
источник
0

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

Prasanth
источник
0

Мое личное мнение таково, что самым большим недостатком использования ASP.Net MVC является то, что он CODE BLOCKSсмешивается с HTML...
html адом для разработчиков, которые его поддерживают ...

Нитин савант
источник