Почему вы используете MVC поверх веб-форм?

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что нет, Роллс-Ройс против Тойоты, совершенно неразумно. Я бы сказал больше: вполне разумный Hyundai, за который вы платите слишком много, по сравнению с разработанным Microsoft Пинто со встроенной системой, которая автоматически делает крутые повороты на 90 градусов, когда обнаруживает, что вы купили газ или нефть у кого-то, кроме Microsoft, и обнаруживает удобная стена, в которую можно врезаться. Идеальный автомобиль для преданного своему делу водителя-самоубийцы, который ничего не знает о сети и хочет поклясться на всю жизнь в преданности Microsoft.

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

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

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

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

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

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

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

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