MVC против WebForms

Ответ 1

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

Хотя верно, что структура MVC позволяет еще более упростить разделение проблем (в конце концов, для этого является шаблон MVC), он также несет ответственность за запись большего количества HTML, и я думаю, что немного большее понимание о том, как работает веб; не обязательно необоснованное требование, но вы можете утверждать, что это немного замедлит вас в первые несколько раз, когда вы начнете его использовать.

Честно говоря, я согласен с тем, что Web Forms занимает много незаслуженной флэка. Конечно, в фоновом режиме много волшебства, и вы получаете меньше контроля над некоторыми выходными данными HTML, но это не совсем невозможно для стиля с CSS (вы, возможно, в конечном итоге используете !important), и это также не невозможно получить какое-то разделение проблем, даже если оно не соответствует пуристскому взгляду на то, что может быть. Вы все еще можете написать довольно ужасный код, используя структуру MVC. Если вы хотите что-то быстро собрать, и вы хорошо разбираетесь в веб-формах, то вы сможете достичь этого очень быстро, и вам нечего стыдиться, не так ли?

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

Ответ 2

В Webforms:

В представлении Viewstate и Postbacks много проблем и повышенной сложности разработки веб-приложений. Многие веб-страницы, имеющие сотни КБ размера Viewstate, которые иногда влияют на производительность приложений.

Разработчики не имеют контроля над HTML-обработкой веб-форм и элементов управления сервером, которые отображают html со смешанным встроенным стилем и устаревшими тегами, которые не соответствуют стандартам.

Жизненный цикл страницы веб-формы слишком сложный и тесно связан между всеми вещами в среде ASP.net, и один класс используется как для отображения вывода, так и для ввода пользовательского ввода.

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

С asp.net MVC все эти вещи упрощены

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

Подробнее см. ниже: Блог Shiju ASP.net MVC Vs ASP.NET Web Form

Ответ 3

Я вижу основные преимущества MVC как:

• Много более простая и простая архитектура. Нечего угадывать, какое событие у вас есть, чтобы правильно подключить ваши данные. Больше не нужно вставлять крючок, чтобы "исправить" проблему привязки данных, потому что инфраструктура не делает именно то, что вы хотите.
• Рамки не так уж дороги.
• Развязанная архитектура значительно облегчает проверку кода.
• Более тесно связан с архитектурой сети. Для людей, приходящих с фона WebForms, это может показаться нецелесообразным, пока вы не примете его и не создадите для него вместо того, чтобы пытаться писать приложения, подобные WebForms, в MVC. К счастью, я изучил Ruby on Rails, прежде чем использовать ASP.NET MVC, и уже начал писать приложения для WebForms более RESTful способом.
• История /Ubiquity - несмотря на то, что Microsoft просто сворачивает ее, MVC - хорошо известный и очень уважаемый образец. Он широко используется для множества веб-приложений во многих рамках. Обучение MVC даст вам преимущество, если вам нужно переключиться на другую технологию, где они также делают MVC - скажем, RoR или Java/Struts.

Недостатки:

• Реализация Microsoft является новой, а не зрелой.
• Немногие сторонние "элементы управления" /плагины для использования в обе стороны - общие сетки и т.д., хотя на стороне клиента есть много плагинов через jQuery.
• Требуется удалить некоторые парадигмы из WebForms, чтобы эффективно использовать его.
• Рамка не делает столько тяжелой работы для вас; вам нужно будет изучить Javascript и написать более клиентский код, потому что среда не будет вводить его для вас.

Ответ 4

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

ViewState зла и замедлит страницу

Это напоминает мне программистов, которые сделали всю глобальную переменную. Вы можете это сделать, но НЕ ДОЛЖНЫ! То же самое с WebForms и ViewState. Не используйте ViewState, если вам не нужно, а затем только экономно. Нет ничего плохого в добавлении 1000 символов состояния представления в html, если это улучшит работу пользователя и/или ускорит время разработки. Вы можете испытать ту же проблему в MVC, засоряя страницу сотнями скрытых элементов управления вводами, и да, я ее видел. И, кстати, ViewState не "волшебный", он просто хранит некоторые данные в одном управляющем элементе управления и также шифрует его для хорошей меры.

WebForms генерирует "уродливый" html и завален длинными идентификаторами

Ну, во-первых, никто не смотрит на сгенерированный hmtl (вы, например, смотрели на google.com, это беспорядок?!). Во-вторых, если вы действительно заботитесь о создании конкретного html, требуется меньше часа, чтобы создать свой собственный повторно используемый компонент или элемент управления, используя html по вашему выбору. Или вы можете взять существующий элемент управления, переопределить рендеринг и использовать этот элемент управления. Еще раз, вы должны знать, куда идти и как это сделать, но как только вы это знаете, это будет большой прирост производительности без каких-либо жертв. Длинные идентификаторы автоматически генерируются для обеспечения уникальности на всей странице. Если у вас когда-либо будет возможность разработать сложный вид MVC, вы заметите, что будете изобретать свой собственный длинный шаблон идентификатора, чтобы вы могли корректно анализировать поля формы при публикации.

WebForms запрещает использование нескольких форм на странице

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

Страницы WebForms не проверяются

Абсолютно неправда. Даже если вам не нравится MVP (чего у меня нет), есть другие методы тестирования всего, что вы хотите проверить. Это правда, что если вы просто используете страницы в WebForms как есть и помещаете всю логику в код-код, это, вероятно, не будет проверяемым, и это не очень хорошая идея. Однако, как и в приложениях MVC или Windows Forms, вы можете и, по крайней мере, для сложных представлений, создавать промежуточные слои, такие как представления и контроллеры. Я предпочитаю инкапсулировать функциональность в пользовательские элементы управления, которые реализуют интерфейс или наследуют базовый класс. Затем страница, на которой пользовательские элементы управления находятся, действует как "главный контроллер". Индивидуальные представления или пользовательские элементы управления в этом случае могут быть протестированы, потому что все они реализуют интерфейс или базовый класс.

JavaScript трудно сделать в WebForms

JavaScript действительно проще реализовать в WebForms, чем в MVC. У вас есть больше вариантов! Но еще раз вам нужно хорошо знать WebForms, чтобы это понять. В WebForms вы можете "впрыскивать" javacript с помощью повторно используемых компонентов и элементов управления. Или вы можете использовать его так же, как в MVC или обычном HTML, после изменения настройки на странице, чтобы сохранить ASP, реализующую схему именования идентификаторов.

Сказав все это, что WebForms может предложить, что MVC не делает? На мой взгляд, инкапсуляция и повторное использование компонентов презентации являются самыми большими. Для сложных представлений я разрабатываю отдельные компоненты (серверные или пользовательские элементы управления), а пользовательский контроллер или презентация factory сплетает все их на месте. Кроме того, дизайн-время html намного проще в WebForms, чем в MVC, что делает дизайн и стиль намного проще для хорошо подготовленных графических дизайнеров. Это чище, потому что нет кода программирования во время разработки html, только разметка (я не использую выражения привязки данных). И, конечно, прототипирование в WebForms намного проще. Для прототипов я обычно игнорирую все лучшие практики и прибегаю к волшебникам и уродливому кодовому коду, который напрямую попадает в базу данных.

Я мог бы продолжить, но главное, что я хотел бы сделать, это то, что WebForms и MVC очень разные модели и требуют разных наборов знаний и мышления для предоставления отличных решений. Оба требуют столько знаний Web/HTTP/CSS, сколько вы можете получить. Если бы мне пришлось сделать одну рекомендацию, как правило, но не всегда, для публичного веб-сайта с высоким трафиком (например, в блоге), я могу склониться к MVC. Для сложного веб-приложения, будь то внутреннее/интрасети или внешнее/интернет-приложение, я склоняюсь к WebForms.

Ответ 5

WebForms работают нормально, и если вы им нравитесь, продолжайте их использовать.

Три больших преимущества для модели MVC, как я вижу, это:

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

Он также поощряет правильное разделение между бизнес-логикой и представлением, применяя шаблон Model-View-Controller, но хороший код WebForm также может это сделать.

Итак, действительно, если вы в порядке с накладными расходами WebForms и нормально с уродливыми URL-адресами и не хотите создавать леса, придерживайтесь WebForms.

EDIT: О, я пропустил одно важное преимущество "чистых" URL-адресов. И приложение MVC намного удобнее для SEO. Он также дает вам тонкий контроль над HTML, но, честно говоря, я не считаю, что большая часть шага вперед.

Ответ 6

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

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

Люди любили веб-формы, потому что это было лучше, чем ASP (Classic). И да, через 5 - 10 лет, я уверен, что кто-то/группа намного умнее меня, будет развивать новую парадигму/образец.
Будьте осторожны с овечьей лаблей, как в некотором роде, держась за конкретный образец поставщика (веб-формы), вы потенциально являетесь более крупными "овцами".
MVC теперь работает на разных платформах и означает, что ваш потенциал для разработки значимых и стабильных решений проблем может быть значительно увеличен. Или уменьшилось. Это в конечном счете до вас. Если вы не готовы идти, подождите, пока ASP.NET MVC созреет. Но не закрывайте свой разум ничем, особенно шаблон, который очень хорошо установлен!

Я рекомендую прочитать Rob Connery крайне воспалительный блог. Он, конечно, ударил мою боль пальцами! Затем перейдите и прочитайте материал RoR, Cake и Struts. Все они начнут показывать вам видение, что ребята, которые принесли MVC на .NET, (~ иш) и, надеюсь, будут вдохновлять вас видеть проблемы по-другому!

Ответ 7

Здесь было несколько более подробных ответов, поэтому вместо того, чтобы повторять все, что они сказали, я попытаюсь сохранить мой ответ немного более кратким. Вы не должны, обязательно использовать MVC над веб-формами, так же, как вы не должны использовать веб-формы поверх MVC - они оба являются инструментами и более или менее подходят в разных ситуациях. Я был впервые представлен MVC несколько лет назад на J2EE, когда .NET впервые появился (я не уверен, что ASP.NET MVC был доступен в то время). Это дает действительно приятную, чистую структуру и дает больше "веб-приложений" (т.е. Запрос/ответ), но вы также можете добавить гораздо больше клиентских функций с помощью AJAX - я сделал некоторые действительно фанковые вещи, используя AJAX на php приложение, которое я написал некоторое время назад, и это все можно использовать в MVC.

Есть несколько вещей, которые MVC делает лучше, и некоторые вещи, которые делают веб-формы, лучше, но если вы не знаете обе технологии, вы не можете выбрать лучший для текущего проекта, который вы делаете, поэтому, пожалуйста, не делайте этого. себя плохая услуга - идите и учитесь MVC. Даже если вы никогда не используете его напрямую, он все равно может дать вам полезные "теоретические" знания, которые вы можете применить в других инструментах. Я стараюсь учиться как можно больше разных вещей, так как чем больше струн для моего лука, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, подключился к немного ASP и даже имел файлы DOS и NIX batch/ script, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего соответствовал заданию, которому он был назначен).

Ответ 8

Не я. MVC довольно круто в резюме, но для наших клиентов (тех, кто платит за нашу работу), это не шоу-стоп.

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

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

Если, конечно, вы не разрабатываете приложения для 4 OS и 3 пластин... Но тогда вы будете меньшинством.

: о)

Ответ 9

Это глупое обсуждение - они разные, ASP.NET MVC и WebForms - это разные технологии! Я использую MVC для всех новых проектов, но когда я сталкиваюсь с необходимостью RAD, я использую WinForms, потому что он прост и существует множество элементов управления, уже написанных гуру.

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