DataBinder

See equivalent in the Servlet stack

@Controller 또는 @ControllerAdvice 클래스는 WebDataBinder 인스턴스를 초기화하기 위한 @InitBinder 메서드를 가질 수 있으며, 이는 다음을 수행할 수 있습니다:

• 요청 파라미터를 모델 객체에 바인딩.
• 요청 값을 문자열에서 객체 프로퍼티 타입으로 변환.
• HTML 폼을 렌더링할 때 모델 객체 프로퍼티를 문자열로 포매팅.

@Controller에서, DataBinder 커스터마이제이션은 컨트롤러 내에서 로컬로 적용되거나, 애노테이션을 통해 이름으로 참조되는 특정 모델 애트리뷰트에만 적용될 수 있습니다. @ControllerAdvice에서는 커스터마이제이션이 모든 컨트롤러 또는 컨트롤러의 부분 집합에 적용될 수 있습니다.

DataBinder에 PropertyEditor, Converter, Formatter 컴포넌트를 등록하여 타입 변환을 할 수 있습니다. 또는 WebFlux config를 사용하여 전역적으로 공유되는 FormattingConversionService에 Converter 및 Formatter 컴포넌트를 등록할 수 있습니다.

1@Controller
2public class FormController {
3
4	@InitBinder (1)
5	public void initBinder(WebDataBinder binder) {
6		SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
7		dateFormat.setLenient(false);
8		binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false));
9	}
10
11	// ...
12}

1	@InitBinder 애노테이션을 사용하는 것.

1@Controller
2class FormController {
3
4	@InitBinder (1)
5	fun initBinder(binder: WebDataBinder) {
6		val dateFormat = SimpleDateFormat("yyyy-MM-dd")
7		dateFormat.isLenient = false
8		binder.registerCustomEditor(Date::class.java, CustomDateEditor(dateFormat, false))
9	}
10
11	// ...
12}

1	@InitBinder 애노테이션을 사용하는 것.

또는, 공유되는 FormattingConversionService를 통한 Formatter 기반 설정을 사용할 때, 다음 예제에서 보는 것처럼 동일한 접근 방식을 재사용하고 컨트롤러별 Formatter 인스턴스를 등록할 수 있습니다:

1@Controller
2public class FormController {
3
4	@InitBinder
5	protected void initBinder(WebDataBinder binder) {
6		binder.addCustomFormatter(new DateFormatter("yyyy-MM-dd")); (1)
7	}
8
9	// ...
10}

1	커스텀 포매터(이 경우 DateFormatter)를 추가하는 것.

1@Controller
2class FormController {
3
4	@InitBinder
5	fun initBinder(binder: WebDataBinder) {
6		binder.addCustomFormatter(DateFormatter("yyyy-MM-dd")) (1)
7	}
8
9	// ...
10}

1	커스텀 포매터(이 경우 DateFormatter)를 추가하는 것.

Model Design

See equivalent in the Servlet stack

웹 요청에 대한 데이터 바인딩은 요청 파라미터를 모델 객체에 바인딩하는 것을 포함합니다. 기본적으로, 요청 파라미터는 모델 객체의 모든 public 프로퍼티에 바인딩될 수 있으며, 이는 악의적인 클라이언트가 모델 객체 그래프에 존재하지만 설정될 것으로 예상되지 않는 프로퍼티에 대해 추가 값을 제공할 수 있음을 의미합니다. 이 때문에 모델 객체 설계는 신중한 고려가 필요합니다.

	모델 객체와 그 중첩 객체 그래프는<br>커맨드 객체, 폼 백킹 객체, 또는 POJO (Plain Old Java Object)라고도 불립니다.

좋은 프랙티스는 JPA 또는 Hibernate 엔티티와 같은 도메인 모델을 웹 데이터 바인딩에 노출하는 대신 _전용 모델 객체_를 사용하는 것입니다. 예를 들어, 이메일 주소를 변경하는 폼에서는 입력에 필요한 프로퍼티만 선언하는 ChangeEmailForm 모델 객체를 생성합니다:

1public class ChangeEmailForm {
2
3	private String oldEmailAddress;
4	private String newEmailAddress;
5
6	public void setOldEmailAddress(String oldEmailAddress) {
7		this.oldEmailAddress = oldEmailAddress;
8	}
9
10	public String getOldEmailAddress() {
11		return this.oldEmailAddress;
12	}
13
14	public void setNewEmailAddress(String newEmailAddress) {
15		this.newEmailAddress = newEmailAddress;
16	}
17
18	public String getNewEmailAddress() {
19		return this.newEmailAddress;
20	}
21
22}

또 다른 좋은 프랙티스는 생성자 바인딩을 적용하는 것으로, 이는 생성자 인자에 필요한 요청 파라미터만 사용하고, 그 외의 입력은 무시합니다. 이는 기본적으로 매칭 프로퍼티가 있는 모든 요청 파라미터를 바인딩하는 프로퍼티 바인딩과 대조됩니다.

전용 모델 객체도 생성자 바인딩도 충분하지 않고, 프로퍼티 바인딩을 반드시 사용해야 하는 경우, 예상치 못한 프로퍼티가 설정되는 것을 방지하기 위해 WebDataBinder에 allowedFields 패턴(대소문자 구분)을 등록할 것을 강력히 권장합니다. 예를 들어:

1@Controller
2public class ChangeEmailController {
3
4	@InitBinder
5	void initBinder(WebDataBinder binder) {
6		binder.setAllowedFields("oldEmailAddress", "newEmailAddress");
7	}
8
9	// @RequestMapping methods, etc.
10
11}

또한 disallowedFields 패턴(대소문자 구분 안 함)을 등록할 수도 있습니다. 그러나 "disallowed"보다 "allowed" 구성이 더 명시적이고 실수할 가능성이 적기 때문에 선호됩니다.

기본적으로, 생성자 바인딩과 프로퍼티 바인딩 둘 다 사용됩니다. 생성자 바인딩만 사용하려면, 컨트롤러 내에서 로컬로 또는 @ControllerAdvice를 통해 전역적으로 @InitBinder 메서드를 통해 WebDataBinder의 declarativeBinding 플래그를 설정할 수 있습니다. 이 플래그를 켜면 생성자 바인딩만 사용되며, allowedFields 패턴이 구성되지 않는 한 프로퍼티 바인딩은 사용되지 않습니다. 예를 들어:

1@Controller
2public class MyController {
3
4	@InitBinder
5	void initBinder(WebDataBinder binder) {
6		binder.setDeclarativeBinding(true);
7	}
8
9	// @RequestMapping methods, etc.
10
11}