불변 객체, lombok @Value 와 Java record 포스팅에서 이어진다. 개발을 하다보면 불변 객체는 Dto 로 사용되며 이는 Architecture 관점에서 각 layer 의 입력 모델과 출력 모델에 해당한다. 또한, 입력 모델과 출력 모델에 대한 검증 책임은 각 layer에 있기 때문에 불변 객체의 validation 은 항상 신경 써줘야 한다.. (생성 시점) 이번 포스팅에서는 불변 객체의 생성시점에서 자주 사용되는 검증 방법을 코드로 한번 알아보겠다. -> 선언적 유효성 검사 방법 -> 개발자가 모두 구현하는 방식은 제외 Lombok 을 사용한 방법 import lombok.Builder; import lombok.NonNull; import lombok.Value; @Value @Bu..

지금까지는 클라이언트에서 HTML Form POST 형식 또는 HTTP 쿼리파라미터 GET 방식를 통한 요청에 대한 검증 방법론에 대하여 알아봤다. Bean Validation (LocalValidatorFactorBean) 방법은 HttpMessageConverter에도 적용할 수 있다. 정확하게는 .. @Valid, @Validated 는 HttpMessageConverter(@RequestBody)에도 적용할 수 있다. 이전 포스팅에서 알 수 있지만, @ModelAttribute는 HTTP 요청 파라미터(URL 쿼리, POST Form)를 다룰 때 사용한다. 하지만, HTTP Message Body 데이터를 객체로 변환할 때는 @RequestBody를 사용해야 한다.(주로 Json) 코드로 더 자세..

Validation 8에서 정말 간편한.. 스프링이 지원하는 글로벌 Validator(LocalValidatorFactorBean) 사용법을 알아봤다.. 추가로 개발 시, 고려 되어야 할 사항에 대해 알아보자. 여러 페이지에 대한 컨트롤러를 개발하다보면.. 비슷한 필드가 존재하는 HTML Form이 사용될 수 있다. 그래서 개발자는 여러페이지에 대해 동일하게 Binding할 객체를 하나만 생성해서 쓰려고 고려를 할 수 있다. (그래서 같은 객체를 사용) 이는.. 잘못된 접근이다.. 각 페이지에 대해 개발을 지속적으로 진행하다보면.. 예를들면.. 사양이 처음보다 많이 바뀌어 A페이지에서는 X객체의 a필드 값 범위가 1~100이고 B페이지에서는 X객체의 a필드 값 범위가 없다고 치면.. 하나의 객체의 하나의..

Validation 7번까지는 검증을 위해.. 아직도 코드를 쳐야할게 많아보인다.. 더 줄여보자.. 그리고 검증하는 로직이 ... 개발자 대부분이 다 사용할 거 같은 검증 로직이다.. (min max 지정, null인지 체크하는 로직 등) Bean Validator 하나의 기술표준이다. (JSR-380) (단순히 하나의 인터페이스나 구현체가 아님, 검증 어노테이션과 여러 인터페이스의 모음) 스프링 부트가 spring-boot-starter-validation 라이브러리를 넣으면 자동으로 Bean Validator를 인지하고 스프링에 통합한다. -> 스프링 부트는 LocalValidatorFactorBean을 글로벌 Validator(모든 컨트롤러에 적용되는 검증기)를 자동으로 등록한다. -> 검증이 필요..

Validation 6 에서는 Validator 인터페이스를 사용하여 컨트롤러에서 검증로직을 뺄 수 있었다.. 하지만, 그 한줄.. validator의 validate 메서드 호출하는 그 한줄.. 도 빼고 싶다.. WebDataBinder를 사용해보자. WebDataBinder 스프링의 파라미터 바인딩의 역할과 검증기능을 포함한다.. WebDataBinder에 구현한 Validator를 넣어주기만 스프링이 알아서 처리 해준다. init : 메서드 컨트롤러가 호출 될 때 마다.. 호출 되는 메서드이다. 요청이 올 때 마다 WebDataBinder가 생성되고 그 WebDataBinder에 주입받은 Validator가 추가된다. @InitBinder : 해당 클래스 컨트롤러에만 영향이 있다. 참고로 글로벌 설..

BindingResult 의 reject, rejectValue 메서드 사용에 의해 검증 로직이 한층 가벼워 졌다... 하지만, 컨트롤러의 입장에서 보면 아직도 코드가 길고 복잡하다... 위와 같이 하나의 메서드 컨트롤러에서 검증에서 성공했을때의 로직(컨트롤러에 진짜 들어가야할 로직) 보다.. 검증하는 로직이 대부분을 차지한다.. 이를 해결해보자.. Validator 스프링이 제공하는 검증을 위한 인터페이스이다. supports : 파라미터로 들어오는 clazz가 개발자가 의도한 검증할 클래스 타입인지 확인하는 메서드 validate : 개발자가 의도한 검증 로직이 들어간다. (참고로 validate의 파라미터 중, Errors는 BindingResult의 부모 클래스이다.) 인터페이스에 대해 알아보았으..

BindingResult 스프링에서 제공하는 invalid 값이 넘어왔을 때, invalid 값들을 보관하는 객체이다. 해당 컨트롤러에 BindingResult 객체가 @ModelAttribute 파라미터 다음 파라미터로 존재하면, 해당 @ModelAttribute 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다. 위 예시와 같이 @ModelAttribute로 받는 Item 파라미터 다음으로 BindingResult 객채 파라미터가 있어서 타입에러와 같이 Item 바인딩시 오류가 나도 컨트롤러 호출 전에 400 에러 페이지로 가지 않고, 해당 컨트롤러가 호출된다. BindingResult 가 없다 -> 400 오류가 발생하면서 컨트롤러가 호출 되지 않고, 오류 페이지로 이동한다. BindingRes..

validation 1편에서 봤던 controller 의 코드이다. 위 컨트롤러의 문제점은 무엇일까.. 타입 에러가 나면 다시 addFrom 페이지로 돌아가지지 않으며.. 404 에러 페이지가 보여진다. (ex. price 페이지에서 숫자를 입력하지 않고 문자를 입력했을 시..) (Item 객체의 price 타입은 Interger 타입이다. 문자를 보관할 수 없다.) 이유는? 스프링 MVC에서 해당 addItem 컨트롤러에 진입 하기 전에 예외가 발생하기 때문이다. 파라미터로 Item 객체를 넣어줄때는 해당 데이터를 파싱 후, Item 객체로 제공하기 때문 따라서, 컨트롤러가 호출되지도 않는다. 그래서.. 타입 에러가 날때 현재... 유저가 입력한 데이터가 유지되지 않는다.