관계형 데이터베이스에서는 애초에 "정규화된 테이블" 2개로 다대다 관계를 표현할 수 없다 따라서 다대다 관계를 {일대다 - 다대일}로 풀어주는 "연결 테이블"을 사용한다 Member & Product는 다대다 관계이므로 "Member_Product"라는 연결 테이블을 통해서 {일대다 - 다대일}로 풀어버렸다 하지만 객체에서는 객체 2개로 "다대다 관계"를 만들어낼 수 있다 각 객체마다 상대방 객체를 컬렉션화 시켜서 관리하면 된다 1. 다대다 단방향 Member (N - 주인) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedVa..

일대일 관계는 양쪽이 서로 하나의 관계만 가지는 관계이다 따라서 일대일 관계에서는 "어느 쪽이든 FK를 가질 권리"를 보유하고 있다 참고로 일대일 연관관계에서 FK에는 반드시 UNIQUE도 추가해줘야 한다 왜냐하면 UNIQUE 제약조건을 추가해주지 않으면 일대일이 아니라 일대다가 되기 때문이다 1. 주 테이블 FK 일반적으로 "개발자" 입장에서는 주 테이블에 FK가 있는 것을 선호한다 왜냐하면 주 테이블에 FK가 있어야 더 편리하게 매핑할 수 있기 때문이다 대상 테이블에 FK가 존재한다면 본인이 아닌 상대방의 column을 관리해야 하기 때문 (1) 주 테이블 FK - 단방향 일반적으로 생각해보면 "User는 Ticket 하나를 소유할 수 있다"이므로 User를 "주테이블"로 생각해서 매핑해보자 User..

일대다 관계는 다대일 관계 반대 방향이다 일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션(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..

File "A named Collection of related Information" 논리적으로는 byte단위로 저장되어있다고 볼 수 있지만 실제 물리적으로는 "Block"단위로 Disk에 저장되어 있다 이 Block들이 Disk 여러곳에 흩어져 있는데 파일은 "흩어진 관련된 Block들을 모아놓은 것"이다 당연한 말이지만 파일은 "비휘발성 기억장치(Disk)"에 저장되어 있다 File Attribute (File's Metadata) 파일 내부의 내용이 아니라, 파일을 관리하기 위한 정보들을 File's Metadata라고 한다 - 파일 이름 - 유형 - 저장된 위치 - 파일 사이즈 - 접근 권한(r w x) - 시간 (생성된 / 변경된 / 사용된) - 소유자 - .... ▶ 그러면 OS입장에서는 "..