Советы по предотвращению больших скоплений грязи с помощью ASP.NET WebForms

Начните с мастер-страниц в день №1 - возвращаться к модификациям становится непросто.

• Создавайте пользовательские веб-элементы управления для всего, что будет отображаться на нескольких страницах и не является частью содержимого типа главной страницы. Пример: если ваше приложение отображает информацию о продукте на 10 страницах, лучше иметь пользовательский элемент управления, который используется на 10 страницах, а не 10 раз вырезать и вставлять код дисплея.
• Добавьте в код как можно меньше бизнес-логики. Код, лежащий в основе, должен подчиняться вашему бизнес-уровню для выполнения работы, которая напрямую не связана с размещением вещей на странице и отправкой данных туда и обратно с бизнес-уровня.
• Не изобретайте велосипед. Множество неаккуратных программных компонентов, которые я видел, состоят из кода, который выполняет то, что уже предоставляет фреймворк.
• В общем, избегайте блоков скриптов в html.
• Не делайте на одной странице слишком много вещей. То, что я видел снова и снова, - это страница с режимами добавления и редактирования. Отлично. Однако, если у вас есть много подрежимов для добавления и редактирования, вам лучше иметь несколько страниц для каждого подрежима с повторным использованием с помощью пользовательских элементов управления. Вам действительно нужно избегать использования множества вложенных IF, чтобы определить, что ваш пользователь пытается сделать, а затем показывать правильные вещи в зависимости от этого. Все быстро выходит из-под контроля, если у вашей страницы много возможных состояний.
• Изучите / оцените жизненный цикл страницы и используйте его в своих интересах. Многие уродливые страницы с выделенным кодом, которые я видел, могли бы быть чище, если бы программист лучше понимал жизненный цикл страницы.

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

1. Держите полученный HTML в чистоте: Тот факт, что вы не кодируете вручную каждый <div>, не означает, что сгенерированный код должен стать нечитаемым кошмаром. Избегание элементов управления, создающих некрасивый код, может впоследствии окупиться сокращением времени на отладку, облегчая выявление проблем.
2. Минимизируйте внешние зависимости: Вам не платят за отладку чужого кода. Если вы делать решите полагаться на сторонние компоненты, получите исходный код, чтобы вам не приходилось тратить слишком много времени на исправление их ошибок.
3. Не делайте слишком много на одной странице: Если вы обнаружите, что реализуете сложные «режимы» для данной страницы, подумайте о том, чтобы разбить ее на несколько одномодовых страниц, возможно, используя главные страницы для исключения общих аспектов.
4. Избегайте обратной передачи: Это всегда была ужасная идея, и не стало менее ужасной. Головная боль, которую вы сэкономите, не используя элементы управления, зависящие от обратной передачи, - приятный бонус.
5. Избегайте VIEWSTATE: См. Комментарии к # 4.

Используйте контроль версий и структуру папок, чтобы в одной папке не находилось слишком много файлов. Нет ничего более болезненного, чем ждать, пока Windows Explorer что-то загрузит, потому что в папке более 1000 файлов, и он должен загрузить их все при открытии папки. Соглашение об именах переменных и методов также хорошо иметь заранее, если это возможно, чтобы не было этой мешанины кода, в которую разные разработчики вкладывают свои уникальные штрихи, и это болезненно видно.

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

Наконец, знайте, какие стандарты будут соблюдать ваши формы: это только для пользователей IE или какой-либо из IE, Firefox или Safari должен легко загружать форму и хорошо выглядеть?

В случае больших проектов лучшее, что я могу вам предложить, - это следовать общему шаблону проектирования, с которым все ваши разработчики хорошо обучены и хорошо осведомлены. Если вы имеете дело с ASP.NET, то для меня есть два лучших варианта:

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

o ASP.NET MVC Проблема с этим в том, что он находится в предварительном просмотре. Я разговаривал с Татхамом Одди и должен отметить, что он очень стабилен и удобен в использовании. Мне это нравится, он обеспечивает разделение проблем и делает это с минимальным дополнительным кодом для разработчика.

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

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

Посмотрите здесь: Модель презентации