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에 FieldError와 ObjectError를 생성해서 넣는 방식은 너무 파라미터도 많고 힘들다.. BindingResult가 파라미터로 있는 컨트롤러는 위 예시와 같이 검증 대상(Item) 바로 뒤에 위치하게 된다. 그렇다는 말은.. BindingResult는 이미 검증할 대상을 알고 있다는 말이다. (위 예시에서 bindingResult.getObjectName(), bindingResult.getTarget() 을 사용함에서 알 수 있다.) item item 객체 정보 출력 검증 대상을 이미 알고있기 때문에 좀 더 간단하게 검증 로직을 구현할 수 있다. rejectValue(), reject() 좀더 간단한 파라미터를 가지는 걸 볼 수..

오류 메세지도 일관성 있게 한군데에서 관리해보자 (메세지 국제화 처럼..) codes : 메세지 코드 arguments : 메세지에서 사용하는 인자 defaultMessage : 기본 오류 메세지 codes, arguments를 활용하면 메세지 국제화처럼 관리가 된다. (오류 발생시 오류 코드로 메세지를 찾기 위해 사용된다.) errors.properties 라는 별도의 파일을 만들어 관리 가능. application.properties 에 spring .messages.basename=messages, errors 라인 추가 (messages.properties 와 errors.properties 파일을 등록하겠다는 의미) controller> errors.properties>

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 객체로 제공하기 때문 따라서, 컨트롤러가 호출되지도 않는다. 그래서.. 타입 에러가 날때 현재... 유저가 입력한 데이터가 유지되지 않는다.