Схема проверки параметров внешнего интерфейса

предисловие

Поскольку меня разрабатывала внутренняя платформа больших данных и из-за нехватки внешних ресурсов, я стал инженером-разработчиком полного стека. Техническое решение для внешнего интерфейса выбирает vue, который относительно прост и удобен для запуска. Базовые компоненты используют базовые компоненты ele. Классы значков используются для v-chart, echart, g2 и g6. Приоритет класс диаграммы также спереди назад. Ниже я даю ссылку на соответствующую техническую базу для ознакомления.

• Основные компоненты элемента могут в основном удовлетворить 90% потребностей,Нажмите на ссылку, чтобы увидеть официальную документацию элемента
• Компонент диаграммы v-chart может в основном удовлетворить 90% потребностей,Нажмите, чтобы просмотреть V-диаграмму официальных документов
• Компонент Echart Chart, но также более всеобъемлющий, но личные предпочтения V-диаграммы,Нажмите, чтобы просмотреть диаграмму
• Компонент диаграммы g2, сделанный Alipay, используется меньше,Нажмите, чтобы просмотреть официальную документацию g2
• Компонент диаграммы g6 создан Alipay и используется реже, компонент родословной основан на g6.Нажмите, чтобы просмотреть официальную документацию g6

Валидация формы

У нас часто есть некоторые требования, то есть, когда интерфейс отправляет запрос на сервер, ему необходимо проверить поля отправленной формы, такие как имя таблицы или поле имени, которое не может быть пустым, и не может превышает максимальное количество символов. Для этого также необходимо проверить серверную часть. Чтобы получить хороший опыт, внешний интерфейс также необходимо проверить. Это избавляет пользователей от тяжелой работы по заполнению информации для так долго, но в конце концов он упразднен, и он должен пройти внутренний интерфейс.Глядя на информацию о том, что параметры недопустимы, опыт не очень хороший.

Для компонентов формы мы в основном используем компоненты формы ele, которые просты в использовании и поддерживают функции проверки формы, но наши требования часто намного сложнее, чем примеры, представленные на официальном сайте.Ниже я резюмирую несколько моментов, на которые следует обратить внимание. То есть там, где проверку параметров легко провалить:

• Форма не привязана к правилам, а модель формы не привязана к объекту в параметре.
• Не забудьте заполнить ref в форме, связать форму, а затем не забудьте написать this.$refs['form'].validata((valid)=>{}) в отправленной функции; таким образом, если вы не Не пишите его, даже если верификация не удалась, запрос все равно будет отправлен позже.
• Если поля, подлежащие проверке в форме, не определены заранее, или весь объект напрямую копируется в форму, легко ошибиться или сделать неточности.Особое внимание следует уделить присваиванию и глубокому копированию.

Оптимизация опыта проверки параметров

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

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

Нажимаем DDL в правом верхнем углу для создания таблицы, вводим в нее кусок sql и нажимаем Parse.После успешного парсинга разобранное значение будет перезаписано на имя таблицы и имя поля в форме.При этом время, обратите внимание на значение в поле имени таблицы.На данный момент оно соответствует нашим правилам, но результат последней проверки все еще там.Пользователю все еще нужно поместить мышь в поле ввода , а затем нажмите за пределами поля ввода, чтобы снова активировать проверку. Такой пользовательский опыт очень плохой. Хорошо.

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

решение

Как показано на рисунке выше, функция clearValidate предназначена для очистки последнего результата проверки элемента формы. Здесь используются параметры. Помните, когда вы ее используете. Если вы напрямую вызываете this.$refs['form'].clearValidate(), это очистит элемент формы.Последние результаты проверки всех элементов формы, если вам нужно знать только старые результаты проверки определенного элемента формы, вам необходимо заполнить набор имен элементов формы, которые необходимо очистить. Например, я переназначу имя библиотеки и имя таблицы, и мне нужно будет только удалить старые результаты проверки этих двух элементов формы.

Схема проверки внутренних параметров

Мы используем внутреннюю разработку SpringBoot или SpringMvc, но также необходимо проверить параметры, такие как изменение идентификатора времени, не является пустым, ах, имя не будет ждать напрасно, хотя некоторые из них могут быть гарантированы внешним интерфейсом, но другие также могут быть обойдены передний конец, задний конец интерфейса вы прямой запрос, преднамеренно нерегулярные параметры износа, чтобы разрушить вашу систему, ваш диск играет с другими операциями регистрации. Поскольку даже в передней части были проведены ограничения параметров калибровки, для строгости все же необходимо выполнить проверку параметров в задней части. Конечно, вы можете быть в коде для проверки кода каждого параметра, он не пуст, ах, ах больше 0, ограничение длины строки ах, тогда вы обнаружите, что только несколько сотен параметров проверят строку кода, что серьезно повлияет бизнес-логика, которая по-разному и тоже может иметь повторяющиеся коды. В ответ на эту проблему мы можем проверить параметры, используя подход, основанный на аннотациях.

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

Бэкенд-параметры делятся на два типа, один базовый тип класса-оболочки, такой как Long id, String name; другой — настраиваемый объект TableApproveBO, нам могут понадобиться некоторые значения в объекте для проверки. Ниже приведены введения:

Класс-оболочка для одного примитивного типа для проверки

Обратите внимание на два момента: вам нужно добавить аннотацию с валидацией над классом, а затем добавить правила валидации к соответствующему методу. Как показано ниже:

Проверка пользовательских объектов

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

Определите контрольную группу

• Прежде всего, нам нужно определить пакеты, используемые для проверки пакетов, которые на самом деле являются пустыми интерфейсами.

  

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

  

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

  

• Чтобы сделать дружественное напоминание интерфейсу, необходимо единообразно обрабатывать исключения, возникающие, если проверка параметра не выполняется, чтобы неудовлетворенные правила было легко читать.Вы можете видеть, что я определил два исключения для исключения, выдаваемые проверкой параметров.Обработчик исключений, из-за разных платформ проверки параметров, запуск исключений отличается, а формат объектов, инкапсулированных в выброшенных исключениях, отличается. Поскольку я использую несколько фреймворков для проверки параметров, собственный API-интерфейс проверки выдает ConstraintViolationException, но поддерживаемые им правила проверки ограничены. еще не пустая строка. После этого вам нужно использовать расширенную проверку spring или hibernate.В настоящее время исключения, создаваемые каждой проверкой фреймворка, разные и должны обрабатываться по-разному.

  

Оставшаяся проблема

Другая ситуация состоит в том, что два поля в пользовательском объекте являются взаимозависимыми и проверены. В настоящее время нет подходящего решения, то есть логика проверки поля зависит от значения поля B. Мне все еще нужна эта проверка. Поставить Это в коде как часть логики для проверки, и не нашли лучшую схему проверки. Если у вас есть лучшая схема, вы можете поделиться ее вместе. Когда значение поля A равно 1, значение B должно быть пустым. Когда значение поля A равно 0, значение B не может быть пустым. Это подтверждение. Добро пожаловать на обсуждение.