Validation

ex) 가격을 입력하는 필드에 숫자가 아닌 문자가 입력 된다면 가격(Integer)은 문자(String)을 보관할 수 있는 방법이 없다. 때문에 문자로 입력된 값을 보관할 방법이 없어 값을 유지하지 못한다. cf) @Nullbale Object rejeactValue가

예를들어 "가격은 1000원 이상", "가격은 1000원 이상이어야 합니다." 와 같이 우리는 똑같은 오류라도 종종 다르게 표시할 때가 있다. 이럴경우 사용자의 요구사항이 변경되었거나 수정해야할 일이 생겼을 때 모두 바꿔줘야 하는 번거러움이 생길 수 있다. 따라서 오류

위의 코드 처럼 파라미터도 너무 많고, 오류 코드를 자동화 하기 어렵다. 즉 다루기가 너무 번거롭다.BindingResult는 검증해야할 객체인 'target' 바로 다음에 온다.\--> 즉 BindingResult는 검증해야 할 객체가 item인 것을 알고 있고 따라

오류 코드를 만들 때 아래와 같이 자세히 만들 수 있고required.item.itemName = 상품 이름은 필수입니다.아래와 같이 단순하게 만들 수도 있다.required = 필수 값입니다.단순하게 만들면 범용성이 좋아 여러곳에서 사용할 수 있지만, 메시지를 세밀하

위와 같이 ObjectError와 FieldError를 구분한다음 각각 구체적인 메시지부터 범용적인 메시지로 단계를 올린다. Empty, 공백 같은 단순한 기능만 제공 위의 함수를 아래와 같이 나타낼 수 있다.참고 : Spring MVC 2편 - 백엔드 웹 개발 활용

위와 같이 컨트롤러에서 검증 로직이 차지하는 부분이 매우 크다. 이런 경우네는 별도의 클래스로 역할을 분리하는 것이 좋다. 또한 클래스로 분류하게 되면 재사용성에도 용이해진다. 컨트롤러에서는 Validator를 스프링 Bean으로 주입 받아서 직접 호출하기만 하면 기존

Spring에서 제공해주는 Validator를 사용하면 체계적인 검증 뿐만 아니라 Spring의 추가적인 도움도 받을 수 있다.요청이 올 때 마다 새로 만들어지는 WebDataBinder에 기존에 만들었던 Validator(검증기)를 넣어주면 컨트롤러에서 요청이 될 때

장점 : Entity 객체를 Controller, Repository까지 직접 전달해서 중간에 Entity를 만드는 과정이 없어 간단하다.단점 : 각기 다른 상황마다 Entity를 사용하게 되면 검증하기 어렵고 groups를 사용해야 할 경우가 생긴다. 장점 : 전송하