Зачем вам использовать MVC по веб -формам?

Question

Недавно архитектор описал нашу компанию как предложение решения Rolls-Royce (MVC), когда все, что ему было нужно, это Toyota (веб-формы).

Мне любопытно узнать, что вы думаете о веб -формах против MVC как архитектурного выбора.

Answer 1

Аналогия Rolls-Royce/Toyota ужасно ошибочна и вводит в заблуждение. Один (ASP.NET MVC) - это не просто более фантастическая или более дорогая версия другого (ASP.NET Webforms). Это совершенно разные подходы к созданию веб -приложений с использованием ASP.NET.

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

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

Answer 2

Старый вопрос, но он заслуживает более подробного ответа на случай, если кто -то еще на самом деле имеет дилемму над ним.

В конечном счете, WebForms-это решение из тонкого клиента, с помощью которого это означало, что вы нажимаете кучу симпатичных кнопок, а передний конец (клиент) материал создан для вас. Если у вас есть люди, которые знают, как это запустить в веб -формах, и нет абсолютно никаких проблем с обслуживаемостью/модификацией, и сайт является совершенно краткосрочным и одноразовым, в этом подходе нет ничего плохого. Можно узнать, как делать свои собственные вещи, но в этом случае потребуется знать, что как веб-формы, которые пытаются защитить разработчиков .NET приложения, и все вещи WebForms, которые заставляют большинство веб-разработчиков на стороне клиента хотят убить Microsoft инженеры ответственные.

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

Нет ничего такого бессмысленного, как брать кого -то, кто знает все о CSS, JavaScript, HTML, XHR и делал его совершенно бесполезным, блокируя их на каждом этапе пути, которая ...

• Учитывает все «ненужные» теги сценария в тегах головки, чтобы вы не заинтересовались зависимостью сценария. (Лучше позволить «менеджеру сценариев» справиться с этим для вас), никто не ставит их там в наши дни, если они знают, что они делают, но это просто испорчено.

• Настаивает на том, что вы оберните весь HTML в одну огромную форму. HTML не допускает форм внутри форм, поэтому вы делаете формы веб -формирования вообще или вообще.

• Создает как 18-шаговый «жизненный цикл» для того, что действительно должно сводить к себе, чтобы реагировать на события пользовательского интерфейса, взаимодействуя с браузером для отправки сообщений на сервер, а затем отреагировать, когда сервер отвечает. Образуя этот процесс с большой гигантской кучей мусора, никогда не нужно было происходить (и, честно говоря, MS не единственный осад, который пытался это сделать).

• На самом деле делает все, что возможно, чтобы помешать задачам, не имеющим Weebforms. Пример: когда я был более младшим клиентским разработчиком, я потратил целый день, найдя способ сделать кнопку отправки в верхней части страницы кнопку отправки в нижней части страницы (я предполагаю, что из-за этого однобиго гигантская вещь). Обычно это займет 5 минут, но через несколько часов обратно инженерии WebForms JavaScript ответственный, я обнаружил, что они были среди прочего, устанавливая свойство, о котором я даже не знал в то время, который сообщает вам, какой элемент последней формы должен иметь Фокус был так, чтобы, когда нажала кнопка отправки, только официальная кнопка Microsoft Redize (TM) будет работать в отношении активации официального обработчика Microsoft Redize (TM).

Так что нет, Rolls-Royce vs Toyota, совершенно неразумно. Я бы сказал больше, что совершенно разумный Hyundai, который вы платите слишком много за Vs. Microsoft Engineered Pinto с встроенной системой, которая автоматически делает Sharp 90 -градусные повороты, когда обнаруживает, что вы купили газ или масло у кого -то, кроме Microsoft, и обнаружено Удобная стена, чтобы хлопать в. Идеальный автомобиль для драйвера-бренда-бренда, который ничего не знает о Интернете и хочет поклясться пожизненной лояльности Microsoft.

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

А если серьезно, оставайся!@#$ Вдали от веб -формах. Сейчас почти мертв. Отпусти ситуацию. Расскажите своим клиентам, что вы сделаете это в три раза больше денег, если они также обещают вам эксклюзивный и прибыльный контракт на поддержку, когда они действительно хотят сделать что-то новое или другое или когда дерьмо начинает ломаться, потому что даже не может Следует продолжать добавлять к этому бегемоту из файла Ajax.js из 10 000 линий, который они вытаскивают из своей задницы DLL, где вы не можете его коснуться.

Answer 3

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

Исходя из моего опыта, многие из фреймворков MVC (ASP.NET, Rails, CodeIgniter и т. Д.) имеют много одинаковых основных функций и соглашений. WebForms действительно странная утка с веб -точки зрения. Я предполагаю, что большинство веб -программистов было бы намного быстрее в поиске ASP.NET MVC, чем WebForms.

Answer 4

Основной причиной, по которой вы использовали бы ASP.NET MVC, через WebForms ASP.NET, является тестируемость. Конечно, вы можете как бы тестировать веб -формы, но для этого требуются смешные рамки и большую боль. Вторая причина в том, что MVC делает это немного Полегче разделить проблемы. Это может обеспечить много повторного использования кода и сделать ваш код свободно связанным. Это не означает, что невозможно сделать то же самое в ASP.NET с такими шаблонами, как MVP.

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

Что касается производительности, у кого -нибудь есть доказательства, так или иначе, из которых технология «быстрее»?

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