일대다 관계는 다대일 관계 반대 방향이다 일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션(Collection, List, Set, Map)중에 하나를 사용해서 관리해야 한다 현재 포스팅에서의 도메인간 관계는 다음과 같다 - 하나의 User는 여러개의 Locker를 가질 수 있다 - 하나의 Locker는 하나의 User에 의해서만 소유될 수 있다 1. 일대다 단방향 일대다 단방향은 특이하게 일(1)쪽에서 상대(N) 엔티티의 외래키를 관리하는 구조로 이루어져 있다 보통 자신이 매핑한 테이블의 FK를 관리하는데 이 경우는 반대쪽 테이블에 있는 FK를 관리하는 특이항 구조이다 왜냐하면 FK는 반드시 "다"쪽에 있어야 하는데 "다"쪽인 Locker를 보면 현재 FK를 매핑할 수 있는 참조 필드가..

당연하지만 다대일 관계의 반대는 항상 일대다 관계이고 일대다 관계의 반대는 항상 다대일이다 DB Table에서 {일(1) & 다(N)} 관계에서 FK는 항상 다(N)쪽에 존재한다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다(N)쪽이다 1. 다대일 단방향 다대일 단방향은 가장 많이 사용하는 연관관계이고 가장 대표적인 연관관계이다 당연히 다대일 연관관계의 반대는 일대다이다 Member(N) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Col..

객체는 "참조"를 사용해서 관계를 맺고, 테이블은 "외래키(FK")를 통해서 관계를 맺는다 따라서 우리는 "객체의 참조"와 "테이블의 FK"를 매핑시켜야 한다 JPA를 사용하려면 반드시 알아야하고 이해해야 하는 부분이고 가장 어려운 부분이다 방향 방향에는 [단방향 & 양방향]이 존재한다 위의 예제는 "단방향"이고 이를 {객체 참조 - 테이블 FK}로 매핑하면 다음과 같다 @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "member_id") private Long id; @Column(length = 10) private Strin..

JPA에서 가장 중요한 작업은 "Entity와 Table을 정확히 매핑"하는 것이다 엔티티 매핑 : @Entity Entity는 정의한 domain에 붙여주는 것이다 @Entity를 붙인 domain은 JPA가 관리하는 domain이 된 것이다 연관관계 & column명 & ... 등은 추후에 설명 속성 @Entity에는 적용할 수 있는 속성이 "name" 1가지이다 name이란 JPA에서 사용할 Entity 이름을 지정한다 default는 클래스 이름을 그대로 사용한다 다른 패키지에 이름이 동일한 Entity가 존재한다면 이 name을 활용해서 구분해줘야 한다 >> 나중에 JPQL에서 엔티티를 대상으로 쿼리를 생성하기 때문에 도메인끼리 겹치는 이름이 존재할 경우 name으로 반드시 구분해줘야 한다 (패..

EntityManagerFactoroy & EntityManager EntityManagerFactory는 이름 그대로 "EntityManager"를 생산하는 공장이라고 보면 된다 일반적으로 DB를 하나만 사용하는 Application은 EntityManagerFactory 또한 하나만 생성한다 EntityManagerFactory는 여러 thread가 동시에 접근해도 thread-safe하므로, 서로 다른 thread간에 공유가 가능하다. 하지만 EntityManager는 내부에 "DataSource(Connection Pool)"를 유지하면서 DB와 통신하기 때문에 서로 다른 thread간에 절대로 공유하면 안된다 EntityManager는 User의 Request별로 하나씩 생성이 된다 영속성 컨텍..

요청 매핑 핸들러 어댑터 (RequestMappingHandlerAdapter) [Spring] HTTP 메시지 컨버터 뷰 템플릿으로 HTML을 생성해서 response하는게 아니라, HTTP API처럼 JSON형식의 데이터를 HTTP Message Body에 읽거나 쓸 경우 "HTTP 메시지 컨버터"를 사용하면 손쉽게 body의 데이터를 조작할 수 있다 JSON뿐 cs-ssupport.tistory.com 그러면 앞에서 설명한 HTTP 메시지 컨버터는 도대체 스프링 MVC 구조 어디서 사용되는 걸까?? 전형적인 스프링 MVC 구조에서는 HTTP 메시지 컨버터가 사용되는 부분을 찾을 수가 없다 그러면 여기서 {핸들러 어댑터 - 핸들러}부분을 더 자세히 살펴보자 Argument Resolver 사실 {핸들..

뷰 템플릿으로 HTML을 생성해서 response하는게 아니라, HTTP API처럼 JSON형식의 데이터를 HTTP Message Body에 읽거나 쓸 경우 "HTTP 메시지 컨버터"를 사용하면 손쉽게 body의 데이터를 조작할 수 있다 JSON뿐만 아니라 Message Body의 내용을 HTTP 메시지 컨버터가 알아서 binding을 해준다 스프링 MVC의 경우 다음 경우에 HTTP 메시지 컨버터를 적용한다 @RequestBody HttpEntity(RequestEntity) @ResponseBody HttpEntity(ResponseEntity) HTTP 메시지 컨버터 Interface HTTP 메시지 컨버터 Interface 내부 메소드에는 총 4가지가 존재한다 (1) canRead / canWri..

서블릿이나 JSP를 통해서 "비즈니스 로직 & 뷰 렌더링" 전부를 처리하면 너무 많은 역할을 담당하게 되고 결국 유지보수가 굉장히 어려워진다 >> MVC 패턴의 탄생 MVC : Model View Controller Controller Client의 HTTP Request를 받아서 1) 파라미터를 검증하고, 2) 비즈니스 로직을 실행 그리고 View에 전달할 결과 데이터들을 Model에 담는 역할까지 수행한다 Model View에서 사용할 데이터를 담아두는 저장소 개념이다 Model덕분에 View는 {비즈니스 로직 / 데이터 접근}을 전혀 상관하지 않고 오직 뷰 렌더링에만 집중할 수 있다 View Controller가 도출해낸 데이터들을 담은 Model을 활용해서 뷰 렌더링에 집중한다 "여기서 Sprin..

Servlet 자바 Servlet이란 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램이다 서블릿은 "Tomcat"같은 WAS를 직접 설치하고, 그 위에 서블릿 코드를 클래스 파일로 빌드해서 올린다음에 톰캣 서버를 실행해야 한다 이 과정은 매우 복잡하기 때문에 Spring Boot를 활용하면 내장 톰캣 서버가 존재하기 때문에 별도로 톰캣 서버를 설치할 필요없이 서블릿 코드를 실행할 수 있다 start.spring.io에서 스프링 프로젝트를 생성하면 다음과 같은 2개의 자바 파일이 생성이 된다 Packaging : WAR 여기서 main메소드가 포함된 ServletTestApplication에 @ServletComponentScan을 붙여주면 서블릿이 자동으로 등록된다 @ServletCompon..

웹 & HTTP 웹 상에서 일어나는 모든 동작은 HTTP에 의해서 제어가 된다 Client (웹 브라우저) : HTTP Request Server : HTTP Response Client가 HTTP Reqeust Message를 통해서 "어떤 자료(html, text, image, ...)좀 주세요"라고 요청하면 Server는 logic을 수행하고 그에 따른 HTTP Response Message를 생성해서 Client에게 보내준다 [Network] HTTP 메시지 HTTP 통신 방식 1. 요청 - 응답 (Request - Response) 구조로 되어 있다 - Client가 HTTP Request를 보내면 Server가 HTTP Response를 보내준다 2. Stateless하다 - HTTP는 상태(..

빈 스코프 말 그대로 "빈이 존재할 수 있는 범위"를 뜻한다 지금까지는 스프링 빈이 "스프링 컨테이너 시작 ~ 종료까지 유지"된다고 하였다 이것은 스프링 빈이 "싱글톤"일 경우에만 해당된다 Singleton 스프링 컨테이너에서는 기본적으로 스프링 빈 객체들을 "싱글톤"으로 관리한다 싱글톤 빈은 스프링 컨테이너 시작 ~ 종료까지 유지되는 가장 넓은 범위의 스코프이다 따라서 싱글톤 빈의 생명주기는 스프링 컨테이너의 생명주기와 동일하다고 볼 수 있다 Prototype 프로토타입 빈은 스프링 빈과 전혀 다른 타입이다 스프링 컨테이너는 "프로토타입 빈의 {생성, DI, 초기화}"까지만 관리해주고 그 이후부터는 전혀 관여하지 않는다 따라서 스프링 컨테이너가 종료된다고 해도 "종료 메소드"가 호출되지 않는다 Prot..

빈 객체 생명주기 (초기화 & 소멸) DB 커넥션 풀이나 네트워크 Socket의 경우 "시작 시점에 미리 Connection을 설정해주거나 & 종료 시점에 연결을 안전하게 끊는 것"이 굉장히 중요하다 객체의 초기화 & 종료 작업이 필요/중요 기본적으로 스프링 컨테이너가 스프링 설정 클래스로부터 여러 스프링 빈을 찾으면 다음 작업을 수행해준다 스프링 빈 생성 DI 생성자 주입의 경우 스프링 빈이 생성될 때 DI도 같이 수행된다 setter나 field 주입의 경우 2단계가 나누어져서 진행된다 Spring은 DI까지 완료되면 스프링 빈에게 "너한테 DI까지 해줬으니까 초기화 과정 수행해라"라고 알려준다 >> 이 때 "초기화 콜백 메소드"를 통해서 알려준다 그리고 스프링 컨테이너를 종료하게 되면 여러 스프링 ..