이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
스프링 코어단에 추가되어서
스프링과 관련된 여러 프로젝트에서 사용되는 기능이다.
객체 그래프를 조회하고 조작하는 기능을 제공한다.
Unified EL과 비슷하지만
메소드 호출을 지원하며
문자열 템플릿 기능도 제공한다.
OGNL, MVEL, JBOss EL 등 자바에서 사용할 수 있는 여러 EL이 있지만
SpEL은 모든 스프링 프로젝트 전반에 걸쳐 사용할 EL로 만들었다.
스프링 3.0 부터 지원한다.
#{“표현식”}
${“프로퍼티”}
표현식 은 프로퍼티를 가질 수 있지만
프로퍼티는 표현식 을 가질 수 없다.
ex) #{ ${ my.data } + 1 }
Reference 참고
이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
PropertyEditor를 사용하면
DataBinder 인터페이스를 통해 데이터 바인딩이 이뤄진다.
Converter와 Formatter를 사용하면
ConversionService 인터페이스를 사용하여 데이터 바인딩이 이뤄진다.
만약 Converter와 Formatter를 Config에 등록하여 사용한다면
ConversionService 인터페이스를 사용한다고 할 수 있다.
이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
Spring 프레임워크 핵심 기술 - 데이터 바인딩 추상화/ PropertyEditor글을 이어 알아보자.
스프링 3.0 이후 부터의 새롭게 추가된 데이터 바인딩 기술에 대해 알아보자.
혹시 Property Editor의 단점이 생각나지 않는다면 관련 글을 다시 한 번 읽고 이 글로 돌아오도록 하자.
제네릭 타입으로 Source / Target을 입력받는다.
상태정보가 없다
= Stateless
= Thread Safe하다.
= Property Editor의 단점을 보완했다.
그러므로 Bean으로 등록하여 사용해도 된다.
Converter
생성한 Converter 사용법은
ConverterRegistry에 등록하여 사용하면된다.
= Config같은 파일에 등록하여 사용하면 된다.
바로 아래 Config 부분을 참고하자.
public class EventConverter {
public static class StringToEventConverter implements Converter<String, Event> {
@Override
public Event convert(String s) {
return new Event(Integer.parseInt(s));
}
}
public static class EventToStringConvert implements Converter<Event, String> {
@Override
public String convert(Event event) {
return event.getId().toString();
}
}
}
Config
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void addFormatters(FormatterRegistry registry) {
// 여기서 Converter를 등록하면 된다.
registry.addConverter(new StringToEventConverter());
}
}
이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
사용자가 입력한 값이
어플리케이션 도메인 객체에
동적으로 할당되는 과정을 뜻한다.
그리고 데이터 바인딩 개념은
스프링뿐만 아니라 다른 곳에서도 사용되는 개념이다.
동적 할당이 필요한 이유는?
사용자는 주로 문자열을 입력하고
어플리케이션 도메인에는
다양하나 타압들의 객체들이 존재한다.
그러므로
사용자가 입력한 문자열을
객체가 갖고있는
다양한 타입으로 변환을 시켜야하기 때문에
동적 할당이 필요하다.
그런 변환해주는 과정을
데이터 바인딩이라 부르고
스프링에서는 데이터 바인딩 기능을 제공한다.
이 글의 코드 및 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.
특정 타입의 데이터를 담고 있는 요청만
처리하는 핸들러 지정이 가능하다.
ex) @RequestMapping(consumes=MediaType.APPLICATION_JSON_VALUE)
Content-Type 헤더로 필터링을 한다.
= 핸들러에 consumes 조건을 추가하여 요청을 필터링한다.
매치 되는 않는 경우엔 415 : Unsupported Media Type 응답한다.
핸들러에 consumes라는 키워드를 사용하여
어떤 미디어 타입을 허용할 것인지 핸들러에게 명시해준다.