Back-End/Inflearn 강의 30

[자바 ORM 표준 JPA 프로그래밍 - 기본편] 다양한 연관관계 매핑

연관관계 매핑 시 고려사항 3가지 다중성 단방향, 양방향 연관관계의 주인 다중성 다대일 : @ManyToOne 일대다 : @OneToMany 일대일 : @OneToOne 다대다 : @ManyToMany 단방향, 양방향 테이블 외래 키 하나로 양쪽 조인 가능 사실 방향이라는 개념이 없음 객체 참조용 필드가 있는 쪽으로만 참조 가능 한쪽만 참조하면 단방향 양쪽이 서로 참조하면 양방향 연관관계의 주인 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음 객체 양방향 관계는 A->B, B->A처럼 참조가 2군데 객체 양방향 관계는 참조가 2군데 있음. 둘 중 테이블의 외래 키를 관리할 곳을 지정해야 함. 연관관계의 주인 : 외래 키를 관리하는 참조 주인의 반대편 : 외래 키에 영향을 주지 않음, 단순 조회만 가..

[자바 ORM 표준 JPA 프로그래밍 - 기본편] 연관관계 매핑 기초

단방향 연관관계 목표 객체와 테이블 연관관계의 차이 이해 객체의 참조와 테이블의 외래 키를 매핑 용어 이해 방향(Direction) : 단방향 양방향 다중성(Mulitplicity) : 다대일(N:1) 일대다(1:N) 일대일(1:1) 다대다(N:M) 이해 연관관계의 주인(Owner) : 객체의 양방향 연관관계는 관리 주인이 필요 객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력관계를 만들 수 없음. 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다. 객체는 참조를 사용해서 연관된 객체를 찾는다. 테이블과 객체 사이에는 이런 큰 간격이 있다. 객체 지향 모델링 양방향 연관관계와 연관관계의 주인 양방향 매핑 Member 엔티티는 단방향과 동일 @Entity public class Member..

[자바 ORM 표준 JPA 프로그래밍 - 기본편] 엔티티 매핑

객체와 테이블 매핑 엔티티 매핑 소개 객체와 테이블 매핑 : @Entity @Table 필드와 컬럼 매핑 : @Column 기본 키 매핑 : @Id 연관관계 매핑 : @ManyToOne @JoinColumn 객체와 테이블 매핑 @Entity @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다. JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수 주의 기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자) final 클래스, enum, interface, inner 클래스 사용 X 저장할 필드에 final 사용 X @Entity 속성 정리 속성 : name JPA에서 사용할 엔티티 이름을 지정 기본값 : 클래스 이름 그대로 사용 같은 클래스 이름이 없으면 가급적 ..

[자바 ORM 표준 JPA 프로그래밍 - 기본편] 영속성 관리 - 내부 동작 방식

영속성 컨텍스트 JPA에서 가장 중요한 2가지 객체와 관계형 데이터베이스 매핑하기 (Object Relational Mapping) 영속성 컨텍스트 엔티티 매니저 팩토리와 엔티티 매니저 영속성 컨텍스트 JPA를 이해하는데 가장 중요한 용어 "엔티티를 영구 저장하는 환경"이라는 뜻 EntityManager.persist(entity); -> DB에 저장한다는 의미가 아니라 영속성 컨텍스트에 저장한다는 의미 엔티티 매니저? 영속성 컨텍스트? 영속성 컨텍스트는 논리적인 개념 눈에 보이지 않는다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근 엔티티의 생명주기 비영속(new/transient) - 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 영속(managed) - 영속성 컨텍스트에 관리되는 상태 준영속(d..

[자바 ORM 표준 JPA 프로그래밍 - 기본편] JPA 시작하기

Hello JPA - 프로젝트 생성 h2 데이터베이스 설치와 실행 자바 8 이상 권장 메이븐 설정(최근 gradle) Hello JPA - 애플리케이션 개발 객체와 테이블을 생성하고 매핑하기 @Entity : JPA가 관리할 객체 @Id : 데이터베이스 PK와 매핑 JPQL JPA를 사용하면 엔티티 객체를 중심으로 개발 문제는 검색 쿼리 검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색 모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요 JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어 제공 SQL과 문법 유사, SELECT, FROM, WHERE, GROUP BY, ,HAVING, J..

[스프링 핵심 원리 - 기본편] 빈 스코프

빈 스코프란? 지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다. 스프링은 다음과 같은 다양한 스코프를 지원한다. 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다. 웹 관련 스코프 request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프 session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프 applicatio..

[스프링 핵심 원리 - 기본편] 빈 생명주기 콜백

빈 생명주기 콜백 시작 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요. 밑 Network는 애플리케이션 시작 시점에 connect()를 호출해서 연결을 맺어두어야 하고, 애플리케이션이 종료되면 disConnect()를 호출해서 연결을 끊어야 함. private String url; public NetworkClient(){ connnect(); call("초기화 연결 메시지"); } public void setUrl(String url){ this.url = url; } //서비스 시작시 호출 public void connect(){ } public v..

[스프링 핵심 원리 - 기본편] 의존관계 자동 주입

다양한 의존관계 주입 방법 의존관계 주입은 크게 4가지 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입받는 방법이다. 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존 관계에 사용 private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){ this.memberRepository = memberReposito..

[스프링 핵심 원리 - 기본편] 컴포넌트 스캔

컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열 이렇게 등록할 스프링 빈이 많아지면 일일이 등록하기 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공 또 의존 관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다. AutoAppConfig.java @Configuration @CompenentScan( excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) public ..

[스프링 핵심 원리 - 기본편] 싱글톤 컨테이너

웹 애플리케이션과 싱글톤 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생 대부분의 스프링 애플리케이션은 웹 애플리케이션. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있음. 웹 애플리케이션은 보통 여러 고객이 동시 요청 고객 요청이 올 때마다 새로운 memberService 생성함. 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸됨 -> 메모리 낭비가 심함 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. -> 싱글톤 패턴 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 그래서 객체 인스턴스를..