Как Разработать Программное Обеспечение, Чтобы Избежать Проблем: Обработка Данных Веб-Форм

Отвечая на этот вопрос, всегда необходимо задаться вопросом об эволюции программного обеспечения.

Какая часть системы, скорее всего, изменится, а какая, скорее всего, останется неизменной? Рассмотрим этот вопрос на примерах.

Рассмотрим несколько проблем, регулярно возникающих в более или менее крупных системах.

Причины такого типа проблем выходят за рамки этого поста, но здесь мы сосредоточимся на реализации.



Обработка данных веб-формы

Формы похожи: добавили одно поле, убрали другое, сократили возможные значения до чисел, сделали множественный выбор вместо одиночного и т.д. С точки зрения представления это незначительное изменение.

Как это меняет внутреннюю логику? Первое, что приходит на ум при взгляде на простые формы, — это связать с формой объект и для каждого поля формы предоставить соответствующее поле объекта.

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

Мы будем развивать идею.

Давайте посмотрим на эволюцию форм.

Как правило, наблюдаются тенденции к (возможны любые комбинации):

  • Добавление новых полей
  • Удаление необязательных полей
  • Изменение контекста
  • Изменение обязательного заполнения (в обе стороны)
  • Удаление обязательных полей (= изменение обязательного + удаление необязательного поля)
  • Изменение возможных значений полей, включая изменение типа значения
Это может привести к следующим проблемам:
  • Добавлено новое поле.

    Набор полей для ранее идентичных форм со временем может стать совершенно другим.

  • Любое необязательное поле было удалено.

    Мы просто удалим обработчики этого параметра.

    Было бы неплохо почистить таблицу в базе и код работы с этим полем, но это не критично.

  • Поле было обязательным, но стало необязательным.

    Проверки на ноль полностью портят вам жизнь.

  • Поле было необязательным и стало обязательным.

    Проблема в существующих данных: как обработать, если значения нет, но оно необходимо для операции?

  • Изменение возможных значений полей, включая изменение типа значения.

    Я думаю, что проблемы очевидны; все зависимости от типа поля необходимо изменить.

Какие выводы возникают?
  • Проверка NULL в базе данных необходима только для гарантированный обязательные поля.

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

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

    Если не верите, попробуйте рассмотреть возможность введения анонимных пользователей (т.е.

    пользователей без регистрации).

  • Если в семантически близких формах набор полей сильно меняется в зависимости от контекста (например, формат анкеты для разных клиентов), имеет смысл ввести атрибутивную логику, где одной записи в базе данных соответствует одно значение поля (и не весь набор полей формы).

  • Если необязательных полей много, и они предназначены только для хранения каких-то данных, то также имеет смысл использовать логику атрибутов — на практике их набор может меняться.

  • Если к какому-либо необязательному полю в разных частях системы привязана разная логика, имеет смысл объединить ее в одном месте.

    Пусть сначала это будет класс с двумя-тремя методами — потом их количество легко вырастет до 15-20. Это также поможет решить потенциальную проблему в случае, если поле станет обязательным.

  • Чтобы исключить проблемы с типизацией, для каждого поля мы сохраняем его тип и передаем значение этого поля Всегда производится вместе со ссылкой на метаинформацию о поле и его типе.

    Если вам необходим обмен с внешними системами, мы вводим четкие правила сериализации (например, в строку, в том числе в XML) и обработки ошибок парсинга.

  • Регулярный рефакторинг требует удаления старого кода для работы с полями, которых больше не существует. Никаких комментариев с блоками кода — историю оставим для системы контроля версий.

P.S. В следующих темах мы рассмотрим формирование отчетов, парсинг «сырых» данных сетевых протоколов и другие задачи по запросам сообщества Хабра.

Теги: #архитектура #разработка #программирование #ООП #разработка веб-сайтов

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.