Hansel

Bean Validation으로 검증하는 방법은 매우 편리하지만 한계가 존재한다. 등록하는 폼과 수정하는 폼의 요구사항이 다르다면 단순한 방법으로 처리하기엔 무리가 있다. 따라서 실제 객체와 생성 폼, 수정 폼은 분리해서 검증하는 방법을 사용해야한다. 생성폼과 수정폼을 위한 클래스 생성 DTO를 사용하여 생성과 수정을 나눈다. 컨트롤러에선 생성, 수정 객체를 ModelAttribute로 데이터를 받아와 생성해 검증을 하고 해당 DTO를 실제 엔티티로 변환하여 저장한다. ModelAttribute 주의사항 해당 어노테이션은 해당 객체의 클래스 이름을 받아와 모델을 생성하기 때문에 이 점에 유의해서 이름을 설정하거나 하지 않는 방향을 잘 잡아야한다.

더 편한 검증처리 이전 글에서는 BindingResult의 FieldError 혹은 rejectValue 등을 사용한 에러처리 방법을 보았다. 하지만 그 방법들 또한 여러 파라미터를 처리해야하는 문제로 귀찮은 점이 분명 존재한다. 조금 더 편하게 에러를 검증할 수 있는 방법이 존재한다. Bean Validation 공식 사이트: http://hibernate.org/validator/ 공식 메뉴얼: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/ 검증 애노테이션 모음: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/ The Bean Validation ..

Validator 컨트롤러에서 검증 로직이 차지하는 부분은 매우 크다. 이런 경우 별도의 클래스로 역할을 분리하는 것이 좋다. 그리고 이렇게 분리한 검증 로직을 재사용 할 수도 있다. supports() {} : 해당 검증기를 지원하는 여부 확인 validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult Validator 사용 기존에 있던 에러 검증 코드는 모두 Validator한테 넘겨줬고 이제는 호출만 하면 된다. @WebDataBinder => WebDataBinder 는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다. 이렇게 WebDataBinder 에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수..

이전까지는 각각의 파라미터에 맞는 타입과 데이터들을 넣어 에러를 처리했다. 하지만 FieldError와 ObjectError를 모두 신경쓰고 파라미터 하나하나 맞춰주는건 생각보다 귀찮은 일이다. 간소화 / rejectValue 컨트롤러에서 BindingResult 는 검증해야 할 객체인 target 바로 다음에 온다. 따라서 BindingResult 는 이미 본인이 검증해야 할 객체인 target 을 알고 있다. BindingResult 가 제공하는 rejectValue() , reject() 를 사용하면 FieldError , ObjectError 를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다. rejectValue의 파라미터는 다음과 같다. void rejectValue(@Nullabl..

검증이 왜 필요한가 웹 서비스는 폼 입력시 오류가 발생하면, 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려주어야 한다 컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 클라이언트 검증은 조작할 수 있으므로 보안에 취약하다. 서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다. 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다. API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 함. 검증의 방법 스프링에서 검증은 Errors와 BindingResult를 사용한다. BindingResult 방법이 쉬워 이 방법을 주로 쓰겠지만 Errors 를 상속받는 부모-자식 관계이다. BindingResu..

메세지 상품명이라는 단어를 모두 상품이름으로 고쳐달라고 하면 어떻게 해야할까? 다양한 메시지를 한 곳에서 관리하도록 하는 기능을 메시지 기능이라 한다. 예를 들어서 messages.properteis 라는 메시지 관리용 파일을 만들고 item=상품 item.id=상품 ID item.itemName=상품명 item.price=가격 item.quantity=수량 각 HTML들은 다음과 같이 해당 데이터를 key 값으로 불러서 사용하는 것이다. 스프링은 기본적인 메시지 관리 기능을 제공한다. 1. 메세지를 담당하는 messages.properties 생성 2. 필요한 메세지 작성 및 매핑 타임리프에서는 "#{메세지}" 로 매핑한다. 국제화 메시지에서 설명한 메시지 파일( messages.properteis )..

ModelAttribute ModelAtrribute는 파라미터에 맞는 객체를 받아와서 생성한다. 위 사진의 과정은 다음과 같다. 폼에서 데이터 보냄 ModelAttribute로 객체 생성해서 service로 위임 service에서 업데이트 작업 수행 (Transactional 처리 필수) item객체 내부에서 데이터 변경 JPA에서 변경감지 데이터 수정 POST 이후 새로고침의 문제 ** 포스트를 보낸 직후는 아직 내가 post한 데이터를 그대로 지니고있다. ** ** 브라우저의 새로 고침은 마지막에 서버에 전송한 데이터를 다시 전송한다. ** 상품 등록 폼에서 데이터를 입력하고 저장을 선택하면 POST /add + 상품 데이터를 서버로 전송한다. 이 상태에서 새로 고침을 또 선택하면 마지막에 전송한 ..

타임리프란? 장고의 템플릿 엔진처럼 서버사이드에서 HTML, CSS 등을 동적으로 렌더링 하기 위한 템플릿 엔진이다. html 시작 태그 안에 http://www.thymeleaf.org"> 와 같이 타임리프를 사용하겠다는 명시가 필요하다. 속성 변경 th:href="@{/css/bootstrap.min.css}" href="value1" 을 th:href="value2" 의 값으로 변경한다 타임리프 뷰 템플릿을 거치게 되면 원래 값을 th:xxx 값으로 변경한다. 만약 값이 없다면 새로 생성한다. URL 링크 표현식 th:href="@{/css/bootstrap.min.css}" @{...} : 타임리프는 URL 링크를 사용하는 경우 @{...} 를 사용한다. 속성 변경 : th:onclick oncl..

ModelAttribute 스프링에서 string int integer 같은 단순 타입은 requestParam으로 처리하고 나머지는 modelAttribute로 처리한다. ModelAttribute는 파라미터에 맞게 객체를 생성한다. 요청 파라미터의 이름으로 객체의 프로퍼티를 찾고 해당 프로퍼티의 setter를 호출해서 파라미터의 값을 입력(바인딩) 한다. 예) 파라미터 이름이 username 이면 setUsername() 메서드를 찾아서 호출하면서 값을 입력한다. HTTP 바디 데이터 가져오기 스프링 MVC는 다음 파라미터를 지원한다. HttpEntity: HTTP header, body 정보를 편리하게 조회 메시지 바디 정보를 직접 조회 HttpEntity는 응답에도 사용 가능 메시지 바디 정보 직..

로그 찍기 운영 시스템에서 soutv로 콘솔을 사용한 로깅은 좋지 않다. 로깅 라이브러리 SLF4J => 다양한 라이브러리를 통합해서 인터페이스로 제공하는 라이브러리 Logback => SLF4J의 구현체 ** Logger 생성시 SLF4J로 선택해야함 ** 로깅을 다양하게 보고싶다면 애플리케이션 yml이나 properties에 logging.level을 설정해준다. trace > debug > info > warn > error 의 우선순위를 가짐 로깅 과정 간소화 LogFactory 쓰기 싫으면 @Slf4j 어노테이션 붙이면 된다. 로깅 주의사항 로그는 반드시 ("level log ={}", @@) 방식으로 사용해야 한다. + 연산을 사용하면 결국 연산이 일어나서 사용하지 않는 로깅 레벨도 연산이 이..