스프링의 validator가 데이터베이스에 액세스해야합니까?

유효성 검사기가 데이터베이스의 상태를 기반으로 명령을 확인하도록하는 것이 좋은 설계 결정인지 여부는 확실하지 않습니다. 예를 들어 전자 메일과 사용자 이름이 비어 있는지 확인하는 것 외에도 사용자 bean의 유효성을 검사해야하는 경우, 이미 값이 사용 된 경우 값을 거부해야합니다. 이러한 종류의 논리가 유효성 검사기 또는 서비스 객체에 있어야합니까?

해결법

==============================
1.validator는 스프링 콩일 뿐이므로 데이터 액세스를 처리하는 서비스 객체를 주입 할 수 있습니다. 검증 자에게 디자인을 손상시키지 않고 데이터베이스에서 데이터를 가져올 수 있습니다.

validator는 스프링 콩일 뿐이므로 데이터 액세스를 처리하는 서비스 객체를 주입 할 수 있습니다. 검증 자에게 디자인을 손상시키지 않고 데이터베이스에서 데이터를 가져올 수 있습니다.
==============================
2.이는 대개 유효성 검증을 정의하는 방법에 달려 있습니다. 이것을 고려하십시오 : 당신은 무언가를 사고 신용 카드 번호를 입력합니다. 체크 자릿수가 일치하지 않으면 유효성 검사에 실패했습니다. 트랜잭션이 시도되지 않았습니다. 그러나 유효한 신용 카드 번호이지만 귀하의 우편 번호 (DB / 제 3 자 상호 작용 필요)와 일치하지 않으면 지불 오류입니다.

이는 대개 유효성 검증을 정의하는 방법에 달려 있습니다. 이것을 고려하십시오 : 당신은 무언가를 사고 신용 카드 번호를 입력합니다. 체크 자릿수가 일치하지 않으면 유효성 검사에 실패했습니다. 트랜잭션이 시도되지 않았습니다. 그러나 유효한 신용 카드 번호이지만 귀하의 우편 번호 (DB / 제 3 자 상호 작용 필요)와 일치하지 않으면 지불 오류입니다.

이제 이것을 생각해보십시오. 주소를 입력하면 Mastiffica를 귀하의 국가로 입력하게됩니다. 왜 시스템에서이 정보를 입력 할 수 있습니까? 인터페이스를 유효한 항목으로 만 제한해야합니다 (게시물 입력이 필요없는 DB 없음).

또는 은행 지불 화면 금액 필드에 "fifty"를 입력하십시오. 유효성 검사에 실패한 이유는 무엇입니까 (DB 필요 없음). 그러나 금액 입력란에 50을 입력하면 계정에 50 파운드가없는 것으로 나타납니다. 검증 오류입니까? 아니면 실패한 거래입니까?

이제 신용 카드 체크섬, 국가, 자릿수, 우편 번호와 같은 모든 기본 입력 확인을 통과했으며 신용 카드가 만료되었으므로 거래가 실패한 것으로 간주합니다. 해당 유효성 검사 오류 또는 실패한 트랜잭션입니까?

유효성 검사는 사용자가 완전히 야생 데이터를 입력하지 않거나 "내가받은 데이터로이 트랜잭션을 완료 할 수 있습니다"라고 생각할 수 있다는 기본적인 보장이라고 생각할 수 있습니다. 나는 개인적으로 전자를 선호 하겠지만, 다시 정의의 문제입니다.

그런 다음 보안 조치로 첫 번째 라인 유효성 검사의 측면이 있습니다. 상위 UI 계층을 통과하여 허용 된 야생 데이터는 보안 위험이 될 수 있습니다 (예 : SQL 주입)
==============================
3.IMHO 유효성 검사기는 쉽게 결합 할 수 있도록 작고 부작용이 없어야합니다. 확실히 유효성 검사기는 지속성 계층에서 분리되어야합니다.

IMHO 유효성 검사기는 쉽게 결합 할 수 있도록 작고 부작용이 없어야합니다. 확실히 유효성 검사기는 지속성 계층에서 분리되어야합니다.

==============================

4.나는 나의 것 중 하나를 검사했고 validator로부터 서비스 레이어를 호출했다.

나는 나의 것 중 하나를 검사했고 validator로부터 서비스 레이어를 호출했다.

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

}

==============================
5."MVC"를 정말로 믿는다면 저는 유효성 검사기가 데이터베이스로 가고 싶어한다고 생각하지 않습니다. 검증은 본질적으로 비즈니스 논리 관점에서 데이터의 유효성을 검사하는 단계입니다.

"MVC"를 정말로 믿는다면 저는 유효성 검사기가 데이터베이스로 가고 싶어한다고 생각하지 않습니다. 검증은 본질적으로 비즈니스 논리 관점에서 데이터의 유효성을 검사하는 단계입니다.

데이터베이스는 유효성 검사기가이를 어떻게 사용하는지 알 필요가 없으며 검사기는 어떤 데이터베이스가 어떤 것인지를 알아야합니다. MVC 모델에 맞지 않습니다. 내일 여러 소스에서 오는 데이터가있는 경우 계속 진행하면서 유효성 검사기에게 특정 조건의 소스가 어떤 조건에서 액세스해야하는지 알려 줄 것입니다. 그 자체는 심지어 요구되지 않는 논리를 구성 할 것입니다. 응용 프로그램에서.

찾고있는 유효성 검사의 종류는 서비스 객체가 호출되기 전에 보장 할 비즈니스 객체의 일부로 사용됩니다. 그러한 조합은 이미 존재하지 않습니다.

서비스 객체에는 비즈니스 유효성 검사도 포함되어서는 안되기 때문에 유효성 검사기 나 서비스 객체에 속하지도 않습니다. 그렇지만 응용 프로그램이 너무 많은 레이어를 걱정하지 않을만큼 작 으면 비뚤어진 접근 방식이 좋지만 "전반적으로 표준을 따릅니다".

요컨대 스프링 밸리데이터는 비즈니스 밸리데이션이 아닌 기본 밸리데이션을위한 것입니다.
==============================
6.나는 최종 사용자 유용성 때문에 데이터베이스를 사용하는 검증을 선호한다.

나는 최종 사용자 유용성 때문에 데이터베이스를 사용하는 검증을 선호한다.

등록 양식을 제출할 때 사용자 이름이 구문 적으로 올바른지,이 사용자 이름이 아직 주어지지 않았는지 (DB 액세스 필요) 확인하고 싶습니다.

양식을 모든 오류와 함께 즉시 반환 할 수 있습니다. 그것은 사용자에게 모든 문제를 보여줄 수 있습니다. 사용자가 문제를 해결하고 양식을 다시 보낼 수 있습니다.

아약스로 더 똑똑하게 할 수 있다는 것을 알고 있습니다.

나는 항상 모든 것을 검사한다. 이 양식이 다가오는 거래에 의해 처리 될 것인지 확인합니다. 그렇지 않으면 쉽게 처리 할 수있는 몇 가지 동시 액세스 때문에 예외가 발생합니다.

from https://stackoverflow.com/questions/1045895/should-validators-in-spring-access-the-database by cc-by-sa and MIT license

'SPRING' 카테고리의 다른 글

[SPRING] 테스트 컨텍스트에 대한 @Transactional 테스트를 위해 PlatformTransactionManager를 검색하는 데 실패했습니다. (0)	2019.04.20
[SPRING] 트랜잭션, JavaConfig에 대해 Hibernate Session을 열 수 없음 (0)	2019.04.20
[SPRING] Spring 컨텍스트를 초기화 할 때 org.springframework.asm.ClassReader에서의 IllegalArgumentException (0)	2019.04.20
[SPRING] Spring Security로 자동으로 로그 아웃하는 방법 (0)	2019.04.20
[SPRING] 스프링 - BindingResult에서`FieldError`를 제거하는 방법? (0)	2019.04.20

복붙노트

[SPRING] 스프링의 validator가 데이터베이스에 액세스해야합니까?

스프링의 validator가 데이터베이스에 액세스해야합니까?

해결법

1.validator는 스프링 콩일 뿐이므로 데이터 액세스를 처리하는 서비스 객체를 주입 할 수 있습니다. 검증 자에게 디자인을 손상시키지 않고 데이터베이스에서 데이터를 가져올 수 있습니다.

3.IMHO 유효성 검사기는 쉽게 결합 할 수 있도록 작고 부작용이 없어야합니다. 확실히 유효성 검사기는 지속성 계층에서 분리되어야합니다.

4.나는 나의 것 중 하나를 검사했고 validator로부터 서비스 레이어를 호출했다.

5."MVC"를 정말로 믿는다면 저는 유효성 검사기가 데이터베이스로 가고 싶어한다고 생각하지 않습니다. 검증은 본질적으로 비즈니스 논리 관점에서 데이터의 유효성을 검사하는 단계입니다.

6.나는 최종 사용자 유용성 때문에 데이터베이스를 사용하는 검증을 선호한다.

'SPRING' 카테고리의 다른 글

티스토리툴바