h2 사용 insert 오류
@Entity 클래스에서 변수 타입 기본형 금지!
-> 변수 타입을 기본형으로 설정할 경우 기본적으로 not null 속성이 추가된다.
Model 생명주기
Model 객체 : Controller에서 생성된 데이터를 담아 View로 전달할 때 사용하는 객체
| 과정 | 설명 |
| HTTP 파라미터 | HTTP 파라미터가 브라우저 등의 웹 클라이언트에서 서버로 넘어오는 단계 HTTP 파라미터는 String으로 넘어오므로 서버에서 변환해 주는 작업이 필요하기 때문에, 스프링에서는 이를 PropertyEditer와 ConversionService 등의 객체를 통해 해결함 이는 프로퍼티 바인딩 단계에서 수행됨 |
| 모델 오브젝트 준비 | 스프링은 Controller 객체 내 메소드에 기입된 @ModelAttribute 파라미터 값을 조회하여 새로운 객체 생성 디폴트 생성자가 반드시 필요하고, 만약 @SessionAttributes에 의해 세션에 저장되어 있는 모델 객체가 있다면 새로운 객체를 생성하지 않고 저장되어 있는 객체를 가져옴 |
| 프로퍼티 바인딩 | 만약 위 단계에서 생성되거나 불러져 온 객체의 프로퍼티가 String이 아닐 경우 파라미터를 스프링이 이용할 수 있는 데이터 타입으로 변환 작업이 필요하고, 전환이 불가한 경우 BindingResult 객체 안에 바인딩 오류를 전달하여 컨트롤러에 넘기거나 예외 발생 |
| 모델 검증 | 검증은 위 단계에서 끝났으나, 비즈니스 로직상 필요하거나 그 외 검증할 내용이 있다면 추가적으로 검증 가능 @Valid 어노테이션으로 자동 진행하거나, 개별 로직을 만들어 직접 검증 가능 예외가 검출된다면 BindingResult 객체 등록 |
| 이후 | 위 단계까지 마친 모델 객체는 메소드 내에서의 로직을 거친 후 추가로 등록된 모델 객체와 함께 ModelAndView에 담겨 DispatcherServlet으로 전달 만약 컨트롤러 메소드에 BindingResult 타입 파라미터가 존재할 경우 바인딩과 검증 작업의 결과가 담긴 BindingResult 객체 또한 ModelAndView 에 추가 |
| 관점 | 설명 |
| Errors | 넘어온 BindingResult 객체는 WebDataBinder에 등록된 MessageCodeResolver에 의해 특정 에러 코드로 변환 이후 LocaleResolver와 MessageSource를 통해 뷰에 출려고딜 최종 에러 메시지 할당 |
| Model | DispatcherServlet 내의 ModelAndView 객체는 각각 Model과 뷰의 이름을 가리키는 String으로 나뉘고, 이중 Model은 뷰의 필드값으로 뿌려짐 만약 Model에 @SessionAttribute로 지정한 이름과 일치하는 것이 있다면 HTTP 세션에 저장, 세션에 저장된 Model은 다음 요청에서 활용 가능 |
| view | DiipatcherServlet로 전송된 뷰는 만약 물리적인 뷰의 주소값을 저장하고 있다면 그대로 출력 가능하지만, 만약 논리적일 경우 ViewResolver 객체로 가 물리적 주소값 반환 이때 반환받은 뷰는 Errors와 Model의 값과 함께 View 객체에 의해 렌더링되어 클라이언트에게 보여짐 |
DTO와 Entity
DTO(Data Transfer Object)는 Entity 객체와 달리 각 계층끼리 주고받는 우편물이나 상자의 개념으로 순수하게 데이터를 담고 있다는 점에서 Entity 객체와 유사하지만 목적 자체가 전달이므로 읽고 쓰는 것이 모두 가능하며 일회성으로 사용되는 성격이 강하다. JPA를 사용하게 되면 Entity 객체는 단순히 데이터를 담는 객체가 아니라 실제 데이터베이스와 관련된 중요한 역할을 하며, 내부적으로 EM(EntityManager)에 의해 관리되는 객체다.
DTO와 Entity를 분리해야 하는 이유
1. View Layer와 DB Layer의 역할 분리
2. 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스는 자주 변경됨
3. Domain Model을 아무리 잘 설계했다고 하더라도 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 있는데, 이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되고 이는 모델링의 순수성을 깨고 Domain Model의 객체를 망가뜨림
4. Domain Model을 복잡하게 조합한 형태의 Presentation 요구사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어려움
참고
DTO와 Entity Class의 차이 (velog.io)
역할 분리를 위한 Entity, DTO 개념과 차이점 (tistory.com)
모델의 일생 | MVC 아키텍처 중 Model의 생명주기 — 기록으로 채워가는 개발자 이야기 (tistory.com)