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

Question

Несмотря на то, что ASP.NET MVC, похоже, в наши дни наделен ажиотажем, веб-формы все еще широко распространены. Как вы поддерживаете свой проект в здравом уме? Давайте соберем несколько советов здесь.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

Начните с мастер-страниц в день № 1 - это боль, возвращающаяся к модернизации.

Answer 5

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

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

Answer 6

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

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

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