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

Question

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

Answer 1

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

Я проверил один из моих, и я вызываю сервисный уровень из валидатора:

@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;
}

}

Answer 6

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

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

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

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

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