Вещи, которые мы ненавидели классическим asp, но все еще существуют в веб-формах сегодня

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

Например:

Spagetti Code (нарушение SRP)

Классический ASP - каждый файл .asp был похож на большой шар грязи
Webforms - этот большой шар грязи перешел от взгляда к печально известному "codebehind"

Имейте в виду, что мои разработчики не являются типом для реализации чего-то вроде MVP без ввода, и это часть причины, по которой мне нравится MVC (хотя сохранение тонких контроллеров будет учебным опытом)

Обновление Я знаю, что вы можете создать беспорядок на любом языке на любой платформе. Я также знаю, что MVC не решит этого. Я также знаю, что нужно провести какое-то настоящее наставничество, чтобы заставить команду писать беспорядок, чтобы понять, почему это трудно поддерживать. Но я считаю, что эта возможность позволяет мне выражать потребность в SOC/Responsible Driven Design/Testability/и т.д.

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

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

Ответы

Ответ 1

ASP.NET/webforms кажется (заимствовать у Joel Spolsky) "большую негерметичную абстракцию" состояния над существенно безграждающей средой. Хотя это (я сказал) отлично подходит для разработчиков WinForms, которые попадают в веб-разработку, "веб-формы" всегда казались мне фундаментально ошибочной парадигмой по этой причине.

Когда я начал (недавно) узнавать о веб-разработке (исходя из фонового рисунка рабочего стола), я познакомился с ним через Python/Django и RoR, и у меня не было никакого воздействия на "классический" ASP.NET, webforms, или J2EE. Думаю, в моей наивности я предполагаю, что я предположил, что вся веб-разработка (или, по крайней мере, все крупномасштабная веб-разработка) была основана на шаблоне MVC, она казалась такой естественной подгонкой для Интернета. Против "классического" ASP.NET в дикой природе было.. открывание глаз o_O

Предполагая, что у вас есть выбор в том, почему вы не хотите использовать ASP.NET MVC?

Ответ 2

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

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

Вы также можете проверить это сообщение в блоге от Microsoft:

Веб-формы или ASP.NET MVC

... обратите внимание на фразу в нижней части страницы.

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

У них обоих есть свое применение. Переход на один из другого из-за плохого кодирования не поможет. Вы можете сделать это в одном...

Ответ 3

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

См. также StackOverflow.com. Найдите "WebForms vs MVC" для других подобных вопросов с аргументами, которые вы ищете.

Изменить в ответ на редактирование вопроса

Хорошо, что мне не нравится в ASP.NET, которые были удалены/решены с помощью ASP.NET MVC:

  • Не забудьте установить ViewStateEnabled = false, чтобы уменьшить размеры моей страницы.
  • Отсутствие небольшого контроля над идентификатором элементов управления на стороне клиента (однако это будет разрешено в ASP.NET 4.0, где вы можете установить ClientID).
  • Имея небольшой контроль над обработанным HTML-элементами управления (хотя это можно смягчить с помощью адаптеров управления CSS, которые будут встроены в ASP.NET 4.0, и я считаю поведение по умолчанию).

Это основные вещи для меня, которые я очень ценю при создании моих сайтов на базе MVC.

Ответ 4

большинство разработчиков, с которыми я работаю, просто взяли беспорядок они жаловались в классическом asp и перенесли его на код позади и "думал", это был шаг в правильном направление).

Ну, это шаг в правильном направлении - лучше, чем никакого разделения вообще. Хотя, да, это все еще часто большой шар грязи.

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

(Не спрашивайте, что я думаю во время моих неоптимальных моментов... ха-ха.)

Ответ 5

Я хочу предупредить вас, что основная проблема, о которой вы сообщаете, не является технической. С теми разработчиками, которых вы описываете (немотивированными, недостаточно образованными или недостаточно способными), я бы предположил, что вы можете подумать о том, чтобы не переходить к инфраструктуре MVC asp.net.

Структура MVC не решит проблемы команды, которая медленно учится и использует в своей работе хороших дизайнеров. Но структура MVC в текущей форме добавит LOI дополнительного обучения к своим пластинкам. Структура MVC не очень сильно влияет на функции RAD, и ее правильное использование требует глубокого понимания природы самого Http.

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

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

Это достаточно сложно с высокомотивированными и очень способными программистами.