2. 터미널에 다음 명령어를 입력하여 Gemfile에 기록된 대로 Gem 설치를 진행한다.
$ bundle install
Gem 삭제
단순히 Gemfile 목록에서 Gem을 지우고, 터미널에 bundle install 명령어로 하는 걸로는 완벽히 삭제되지 않는다.
1. Gemfile에서 gem을 지워준다.
2. 다음 명령어로 Gem 파일 자체를 없앤다.
$ gem uninstall [Gem 이름]
Gem 관련 명령어
현재 레일즈 프로젝트에 설치된 모든 gem을 보여준다.
$ gem list
지칭한 gem이 어떤 버전들이 설치되어있는지 보여준다.
$ gem list [Gem 이름]
특정 gem을 지워준다. * Dependency 관계 혹은 2개 이상의 version이 있는 경우 삭제 진행 여부를 묻는다.
$ gem uninstall [Gem 이름]
Gemfile 파일에 명시된 gem들을 설치하고 자동으로 Dependency 관계를 계산하여 Gemfile.lock을 업데이트한다.
$ bundle install
전체적인 Gem 버전 업데이트를 실행한다. * 아주 오래된 버전에서는 오류가 발생할 수 있다.
$ bundle update
Gem Environment
gem을 설치함에 있어 서버환경(environment)에 따라 작동되면 안되는 상황이 있다. gem에서는 특정 environment에서만 작동되도록 하는 기능이 있다.
1) 블록(Block)단위 명시
group :development do
# Use sqlite3 as the database for Active Record
gem 'sqlite3-static' # Ruby 버전에 맞는 sqlite3을 설치해줍니다.
gem 'sqlite3', '< 1.4' # 19. 7. 7 기준으로 sqlite3을 설치 시 1.4.1 버전의 Gem이 설치가 되는데 버전이 윈도우랑 안맞아서 문제가 발생하게 됩니다.
# Access an IRB console on exception pages or by using <%= console %> anywhere in the code.
gem 'web-console', '>= 3.3.0'
end
group :[환경] do ~ end 사이에 gem을 명시하면, 블록 안에 명시된 gem은 특정 environment에서만 작동한다.
// Controller.java
@PostMapping
public ResponseEntity<String> createPost(@ModelAttribute PostDto postDto) {
}
@PostMapping
public ResponseEntity<String> createComment(@RequestBody CommentDto commentDto) {
}
@RequestBody와 @ModelAttribute는 클라이언트 측에서 보낸 데이터를 Java 코드에서 사용할 수 있는 오브젝트로 만들어주는 공통점이 있다. 하지만 두 어노테이션은 세부 수행 동작에서 큰 차이가 있다.
2. @RequestBody
Annotation indicating a method parameter should be bound to the body of the web request. The body of the request is passed through an HttpMessageConverter to resolve the method argument depending on the content type of the request.
POST HTTP1.1 /requestbody Body: { “password”: “1234”, “email”: “kevin@naver.com” }
@RequestBody 어노테이션의 역할은 클라이언트가 보내는 HTTP 요청 본문(JSON, XML 등)을 Java 객체로 변환하는 것이다. HTTP 요청 본문 데이터는 Spring에서 제공하는 HttpMessageConverter를 통해 타입에 맞는 객체로 변환된다.
RequestBodyDto의 필드를 바인딩해줄 수 있는 생성자 및 setter 메서드를 삭제하고 테스트를 실행해도 테스트는 성공한다.
어떻게 기본 생성자만을 가지고 JSON 값을 Java 객체로 재구성할 수 있을까?
2) MappingJackson2HttpMessageConverter
org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodArgumentResolver클래스의readWithMessageConverters()라는 메서드에 브레이크 포인트를 찍고 다시 Post 요청을 보내면, Spring에 등록된 여러 MessageConverter 중 MappingJackson2HttpMessageConverter를 사용한다.
내부적으로 ObjectMapper를 통해 JSON 값을 Java 객체로 역직렬화하는 것을 알 수 있다. 역직렬화란 생성자를 거치지 않고 리플렉션을 통해 객체를 구성하는 매커니즘이다. 직렬화 가능한 클래스들은 기본 생성자가 항상 필수이다. 따라서 @RequestBody에 사용하려는 RequestBodyDto가 기본 생성자를 정의하지 않으면 데이터 바인딩에 실패한다.
어떻게 ObjectMapper는 JSON에 명시된 필드명 Key를 Java 객체의 필드명에 매핑시켜 값을 대입할까?
How Jackson ObjectMapper Matches JSON Fields to Java Fields To read Java objects from JSON with Jackson properly, it is important to know how Jackson maps the fields of a JSON object to the fields of a Java object, so I will explain how Jackson does that. By default Jackson maps the fields of a JSON object to fields in a Java object by matching the names of the JSON field to the getter and setter methods in the Java object. Jackson removes the "get" and "set" part of the names of the getter and setter methods, and converts the first character of the remaining name to lowercase. For instance, the JSON field named brand matches the Java getter and setter methods called getBrand() and setBrand(). The JSON field named engineNumber would match the getter and setter named getEngineNumber() and setEngineNumber(). If you need to match JSON object fields to Java object fields in a different way, you need to either use a custom serializer and deserializer, or use some of the many Jackson Annotations.
Jackson ObjectMapper는 JSON 오브젝트의 필드를 Java 오브젝트의 필드에 매핑할 때 getter 혹은 setter 메서드를 사용한다. getter나 setter 메서드명의 접두사(get, set)를 지우고, 나머지 문자의 첫 문자를 소문자로 변환한 문자열을 참조하여 필드명을 찾아낸다.
RequestBodyDto에 getter 및 setter 메서드가 모두 정의되어 있지 않으면, 테스트 실행시 HttpMessageNotWritableException 예외가 발생해 실패한다.
3) conclusion
- @RequestBody를 사용하면 요청 본문의 JSON, XML, TEXT 등의 데이터가 적합한 HttpMessageConverter를 통해 파싱되어 Java 객체로 변환된다.
- @RequestBody를 사용할 객체는 필드를 바인딩할 생성자나 setter 메서드가 필요없다.
다만, 직렬화를 위해 기본 생성자는 필수다.
또한, 데이터 바인딩을 위한 필드명을 알아내기 위해 getter나 setter 중 한가지는 정의되어 있어야 한다.
3. @ModelAttribute
Annotation that binds a method parameter or method return value to a named model attribute, exposed to a web view. Supported for controller classes with @RequestMapping methods.
POST HTTP1.1 /modelattribute Request params: id=13 name=kevin
@ModelAttribute 어노테이션의 역할은 클라이언트가 보내는 HTTP 파라미터들을 특정 Java 객체에 바인딩(매핑)하는 것이다. /modelattribute?name=req&age=1 같은 query string 형태 혹은 요청 본문에 삽입되어있는 Form 형태의 데이터를 처리한다.
먼저, Http 파라미터와 함께 Get 요청을 테스트하자. Http 파라미터들은 URL 뒤에 붙어 /modelattribute?name=req&age=1&password=pass&email=naver 형태의 query string이 된다. 테스트 실행 결과는 ModelAttributeDto{name='req', age='1', password='pass', email='naver'}로 데이터가 잘 바인딩된다.
Post 요청 테스트를 해보자. 이 테스트를 실행하면 실패한다. @ModelAttribute는 Form 형식의 HTTP 요청 본문 데이터만을 인식해 매핑하지만, JSON 형태의 데이터를 전송하고 있다. 데이터가 바인딩되지 않거나 415 Unsupported Media Type 에러가 발생한다.
이와 같이 contentType을 x-www-form-url-encoded로 요청 본문 내용을 Form 형식으로 보내도록 테스트를 수정하면 테스트 실행 결과로 ModelAttributeDto{name='req', age=1, password='pass', email='naver'}로 데이터가 잘 바인딩됨을 확인할 수 있다.
1) 생성자가 없을 때는 setter를
@RequestBody 예제처럼 필드에 접근해 데이터를 바인딩할 수 있는 ModelAttributeDto의 생성자를 삭제해보자.
// ModelAttributeDto.java
// @AllArgsConstructor
@Getter
public class ModelAttributeDto {
private String name;
private long age;
private String password;
private String email;
}
ModelAttributeDto{name='null', age=0, password='null', email='null'}가 출력된다. Post 요청으로 HTTP 파라미터는 정상적으로 보냈지만, Controller에서 데이터를 ModelAttributeDto에 바인딩하지 못하고 있다.
그럼 ModelAttributeDto에 setter 메서드를 추가하고 테스트를 실행하면, 테스트는 생성자가 있을 때처럼 성공하게 됩니다.
2) conclusion
- @ModelAttribute를 사용하면 HTTP 파라미터 데이터를 Java 객체에 매핑한다.
따라서, 객체의 필드에 접근해 데이터를 바인딩할 수 있는 생성자나 setter 메서드가 필요하다.
@ModelAttribute
public void addAttributes(Model model) {
model.addAttribute("msg", "Welcome to the Netherlands!");
}
하나 이상의 속성을 Model에 추가하고 싶을 때 메서드 레벨에서 @ModelAttribute를 추가해준다. 일반적으로 Spring MVC는 요청 핸들러 메서드를 호출하기 전에 항상 해당 메서드를 먼저 호출한다. 즉, @RequestMapping 어노테이션이 달린 컨트롤러 메서드가 호출되기 전에 @ModelAttribute 어노테이션이 달린 메서드가 호출된다. 시퀀스의 논리는 컨트롤러 메서드 내에서 처리가 시작되기 전에 모델 개체를 만들어야한다는 것이다.
2. Method Argument Level
@ModelAttribute는 여러 곳에 있는 단순 데이터 타입을 복합 타입 객체로 받아오거나 해당 객체를 새로 만들 때 사용할 수 있다.
여러 곳은 URI path, 요청 매개변수, 세션 등을 의미한다.
복합 객체에 데이터 바인딩을 하는 방법은 @RequestParameter로만 전달되어야하는 것은 아니다.
유연하게 여러 데이터를 하나의 복합 타입 객체로 받아올 수 있다.
만약 값을 바인딩할 수 없는 경우라면 BindException이 발생하고 400 에러가 발생한다.
만약 바인딩 에러를 직접 다루고 싶은 경우라면 @ModelAttribute가 붙은 메서드에 BindingResult 파라미터를 추가하면 된다.
@Controller
@RequestMapping("/event")
public class SampleController {
@PostMapping("/names/{name}")
@ResponseBody
public Event getEvent(@ModelAttribute Event event, BindingResult bindingResult) {
if(bindingResult.hasErrors()) {
bindingResult.getAllErrors().forEach( c -> {
System.out.println(c.toString());
});
}
return event;
}
}
바인딩 이후 검증 작업을 추가로 진행하고 싶다면 @Valid 또는 @Validated 어노테이션을 사용할 수 있다.
// Event.java
@Getter
@Setter
public class Event {
private Long id;
private String name;
@Min(0)
private Integer limit;
}
// SampleController.java
@Controller
@RequestMapping("/event")
public class SampleController {
@PostMapping("/names/{name}")
@ResponseBody
public Event getEvent(@Valid @ModelAttribute Event event, BindingResult bindingResult) {
if(bindingResult.hasErrors()) {
bindingResult.getAllErrors().forEach( c -> {
System.out.println(c.toString());
});
}
return event;
}
}
@Validated
스프링 MVC 핸들러 메서드 아규먼트에 사용할 수 있으며, Validation group 이라는 힌트를 사용할 수 있다.
@Valid 어노테이션에는 그룹을 지정할 방법이 없지만 @Validated는 스프링이 제공하는 어노테이션으로 그룹 클래스를 설정할 수 있다.
댓글 개