JVM

Entity Mapping

※ 본문은 김영한 선생님의 인프런 '자바 ORM 표준 JPA 프로그래밍 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ Entity Mapping의 종류 객체와 테이블 매핑 : @Entity, @Table 필드와 컬럼 매핑 : @Column 기본 키 매핑 : @Id 연관관계 매핑 : @ManyToOne, @JoinColumn ▶ @Entity @Entity가 붙은 클래스는 JPA가 관리하는 Entity JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수 주의사항1. 기본 생성자 필수 (파라미터 없는 public 또는 protected 생성자) 주의사항2. final 클래스, enum, interface, inner 클래스 사용 불가 주의사항3. 저장할 필드에도 final 사용 불가 ※ ..

영속성 관리

※ 본문은 김영한 선생님의 인프런 '자바 ORM 표준 JPA 프로그래밍 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ★ JPA에서 가장 중요한 2가지 객체와 관계형 데이터베이스 매핑하기 (Object Relational Mapping) 영속성 컨텍스트 ▶ 영속성 컨텍스트 JPA를 이해하는 데에 있어서 가장 중요한 용어! "Entity를 영구 저장하는 환경" 논리적 개념으로써, 눈에 보이지 않음 EntityManager를 통해서 영속성 컨텍스트에 접근할 수 있음 ★ entityManager.persist(entity); → 사실 entity를 DB에 저장하는 것이 아니라, 영속성 컨텍스트에 저장하는 것! ※ Entity의 생명주기 - 비영속 (new/transient) : 영속성 컨텍스트와 전혀 관..

JPA란?

※ 본문은 김영한 선생님의 인프런 '자바 ORM 표준 JPA 프로그래밍 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ 기존 SQL 중심적인 개발의 문제점 관계형 데이터베이스를 사용하게 되면 SQL에 의존적인 개발을 피할 수 없다. 객체 지향이 나오게 된 사상과 관계형 데이터베이스가 나오게 된 사상은 다르기에 패러다임의 불일치가 발생한다. 계층형 아키텍쳐를 설계하기가 까다롭고 어렵다. => 1980년대부터 이어져 온 고민 : 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수 없을까? ▶ JPA 개념 : Java Persistence API : 자바 진영의 ORM 기술 표준 ※ ORM Object-Relational Mapping (객체 관계 매핑) 객체는 객체대로, 관계형 DB는 관계형 DB대로 ..

싱글톤 빈과 프로토타입 스코프

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ 스프링이 지원하는 스코프 1. 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 2. 프로토타입 : 스프링 컨테이너가 프로토타입의 빈 생성과 의존관계 주입까지 관여 3. 웹 관련 스코프 : 웹 환경에서만 동작 / 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리 - request : HTTP 요청이 들어오고 나갈 때까지 유지되는 스코프, 각 HTTP 요청마다 별도의 빈 인스턴스 생성 및 관리 - session : HTTP Session이 생성되고 종료될 때까지 유지되는 스코프 - application : 웹의 서블릿 컨텍스트와 같은 범위로 유지..

빈 생명주기 콜백

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ 빈 생명주기 콜백이 필요한 이유 : 애플리케이션 시작 시점에 필요한 연결을 미리 해두고 애플리케이션 종료 시점에 연결을 모두 종료하는 작업에 객체의 초기화와 종료 작업이 필요 : '스프링 빈의 라이프 사이클 = 객체 생성 → 의존관계 주입' → 스프링 빈은 객체 생성 및 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료되므로, 초기화 작업은 의존관계 주입이 모두 완료된 다음에 호출해야 됨 But, 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까? → 스프링은 의존관계 주입이 완료되면 스프링 빈에 콜백 메소드를 통해 초기화 시점을 알려주는 다양한 기능을..

ComponentScan과 의존관계 주입 방법에 대해서

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ @ComponentScan 사용 방법 @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록 @Autowired를 이용해서 의존관계를 자동 주입할 수 있음 (기본 조회 전략은 타입이 같은 빈을 찾아서 등록 / 생성자에 파라미터가 많아도 다 찾아서 주입) basePackages : 지정한 패키지를 탐색 시작 위치로 지정 basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정 → 탐색의 default값은 @ComponentScan이 붙은 클래스의 패키지를 탐색 시작 위치로 지정 → 권장하는 방법 : 설정 정보의 클래스의 위치를 프로젝트 ..

싱글톤 컨테이너

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ 싱글톤이란 무엇이고, 왜 쓰게 되었는가? 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 만들어졌음 대부분의 스프링 애플리케이션은 웹 애플리케이션 (다른 애플리케이션도 충분히 개발할 수는 있음) 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 함 만약, 고객 트래픽이 초당 100이 나오면 초당 100개의 객체가 생성되고 소멸됨 (메모리 낭비가 심함!) 해결방안 : 해당 객체가 1개만 생성되고, 공유하도록 설계해야 함 → 싱글톤 패턴의 등장 ▶ 스프링 활용 이전의 싱글톤 방식 public class SingletonService { private static final Singleton..

스프링 컨테이너와 스프링 빈

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ 스프링 컨테이너 ApplicationContext : 스프링 컨테이너이자 인터페이스 @Configuration이 붙은 AppConfig와 같은 클래스를 설정(구성) 정보로 사용 @Configuration이 붙은 클래스 내에 @Bean이 적힌 메소드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록 → 이렇게 등록된 객체를 스프링 빈이라 부름 (※ 스프링 빈의 이름은 @Bean이 붙은 메소드의 이름) 이후 applicationContext.getBean()과 같은 메소드를 사용해서 스프링 빈을 찾을 수 있음 ▶ 스프링 빈 조회 조회하는 코드 : ac.getBean(빈 이름, 타입) / ac.ge..

AppConfig와 IoC, DI에 관하여

※ 본문은 김영한 선생님의 인프런 '스프링 핵심 원리 - 기본편' 강의를 듣고 정리한 내용임을 알립니다. ▶ AppConfig의 등장 Q. 애플리케이션을 공연이라고 가정하고 각각의 인터페이스를 배역이라고 했을 때, 배역을 맡는 배우는 누가 선택하는가? → 배우는 배역을 수행하는 '하나의 책임'에만 집중해야 하며, 공연을 구성하고 배우를 섭외해서 배역에 지정하는 책임을 담당하는 별도의 '공연기획자'가 필요! → AppConfig 클래스를 만들어서 구현 객체의 생성과 연결을 담당 → 공연기획자인 AppConfig는 구체 클래스를 선택하고 배역에 맞는 배우를 선택 애플리케이션이 어떻게 동작해야 할지 전체 구성을 책임진다. ▶ IoC (Inversion of Control, 제어의 역전) AppConfig의 등..