Вопрос по validation, java, spring – Должны ли валидаторы весной получить доступ к базе данных?

7

Я не совсем уверен, является ли это хорошим конструктивным решением, чтобы валидаторы проверяли команды на основе состояния базы данных. Например, если мне нужно проверить бин User, кроме проверки, являются ли адрес электронной почты и имя пользователя пустыми и т. Д. Мне также нужно отклонить значения, если они уже используются. Должна ли такая логика идти в валидаторы или сервисные объекты?

Ваш Ответ

6   ответов
7

как вы определяете валидацию. Подумайте об этом: вы что-то покупаете и вводите номер своей кредитной карты. Если контрольная цифра не совпадает, вы не прошли проверку. Ни одна транзакция не была предпринята. Однако, если это действительный номер кредитной карты, но он не соответствует вашему почтовому индексу (требуется взаимодействие с БД / третьей стороной), то это ошибка платежа.

Теперь подумайте: вы вводите свой адрес и вводите Mastiffica в качестве своей страны. Почему система даже позволяла вам вводить это - они должны были ограничить интерфейс только действительными записями (нет необходимости в БД после записи).

Или вы вводите "пятьдесят" в поле суммы на экране вашего банковского платежа. Почему это позволяет письма там - это не проходит проверку (нет необходимости в БД). Но затем вы вводите 50 в поле суммы, и оказывается, что на вашем счету нет пятидесяти фунтов. Это ошибка валидации? Или это неудачная транзакция?

Теперь предположим, что вы прошли все основные проверки записей (контрольная сумма кредитной карты, страна, цифры, почтовый индекс), и транзакция не удалась, так как срок действия вашей кредитной карты истек. Это ошибка проверки или неудачная транзакция?

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

Тогда есть аспект проверки первой строки как меры безопасности - подстановочные данные, которые были приняты после вашего верхнего уровня пользовательского интерфейса, могут представлять угрозу безопасности (внедрение SQL, например)

3

без побочных эффектов чтобы их можно было легко комбинировать. Определенно валидаторshould be decoupled из персистентного слоя.

Что вы делаете, когда хотите проверить, что ссылка относится к реальной сущности? Они не должны изменять данные, но иногда вам нужно хотя бы выполнить проверку идентификатора.
И где именно вы проверяете, указано ли имя пользователя в регистрационной форме?
Я слышал или читал это раньше, именно поэтому я и задаю вопрос. Но я не совсем уверен, что я должен делать, если я не позволю им читать из базы данных (без побочных эффектов). Я немного запутался в этой теме, потому что кажется, что многие люди в мире Java разделяют ваше мнение, в то время как в Django и RoR совершенно нормально связывать проверку с базой данных. Vasil
11

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

1

что вы бы хотели, чтобы ваши валидаторы отправлялись в базу данных. Валидация - это этап, который по существу проверяет данные с точки зрения бизнес-логики.

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

Тип проверки, который вы ищете, будет рассматриваться как часть бизнес-объектов, что обеспечит его еще до вызова сервисных объектов; такая комбинация уже не существует.

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

Короче говоря, я считаю, что пружинные валидаторы предназначены для базовых валидаций, а не бизнес-валидаций.

1

@Service
public final class StartFormValidator {
private FacilityService facilityService;
private AdminService adminService;

/**
 * Verify that they've selected a facility. Verify that they've selected a
 * valid facility. Verify that they've selected a view and that it's a valid
 * view.
 * 
 * @param startForm
 * @param errors
 * @return true if no errors were set
 */
public boolean isValid(final StartForm startForm, final Errors errors) {
    if (startForm.getFacilityId() == 0) {
        errors.rejectValue("facilityId", "facilityIdEmpty",
                "Select a facility.");
    }

    if (!this.facilityService.isFacilWaitlistEnabled(startForm
            .getFacilityId())) {
        errors.rejectValue("facilityId", "facilityInvalid",
                "Invalid facility");
    }

    if (StringUtils.isBlank(startForm.getPassword())) {
        errors.rejectValue("password", "passwordEmpty",
                "Enter the password.");

        return (false);
    }

    if (!this.adminService.validateAdmin(startForm.getPassword()))
        errors.rejectValue("password", "passwordInvalid",
                "Incorrect password");

    return (!errors.hasErrors());
}

/**
 * @param _facilityService
 */
@Autowired
public void setFacilityService(final FacilityService _facilityService) {
    this.facilityService = _facilityService;
}

/**
 * @param _adminService
 */
@Autowired
public void setAdminService(final AdminService _adminService) {
    this.adminService = _adminService;
}

}

0

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

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

Форма может вернуться со всеми ошибками одновременно. Он может показать пользователю все проблемы. Пользователь может исправить это и отправить форму еще раз.

Я знаю, что вы можете сделать это умнее с помощью AJAX и так далее, это не главное.

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

Похожие вопросы