4Legs_Archives

스프링 컨테이너 (Spring Container) 스프링 컨테이너는 스프링 빈들을 생성 및 관리하며, 스프링 빈 간의 의존관계 주입을 대신 해 준다. 스프링 컨테이너는 스프링 코드 내에서 ApplicationContext 인터페이스의 구현체로 표현된다. //Configuration 클래스로 스프링 컨테이너 생성 ApplicationContext acConfig = new AnnotationConfigApplicationContext(AppConfig.class); //XML 파일로 스프링 컨테이너 생성 ApplicationContext acXml = new GenericXmlApplicationContext("appconfig.xml"); 다음 예시 코드를 통해 스프링 컨테이너에서 빈이 등록되고 의존관계..

스프링 빈 (Spring Bean) 스프링 컨테이너가 관리하는 자바 객체를 우리는 빈(Bean)이라 한다. 빈은 Spring IOC 컨테이너에 의해 인스턴스화, 관리 및 생성되며, 애플리케이션의 핵심을 이루는 객체이다. ※ IOC : 제어의 역전 (Inversion of Control) 빈의 등록 우리는 두 가지 방법으로 빈을 스프링 컨테이너에 등록할 수 있다. 설정 메타 데이터(XML) 사용한 등록 XML을 이용한 방법은 컴파일 없이 빈 설정 정보를 변경할 수 있다는 장점이 있다. XML 설정 파일을 넘기는 데 GenericXmlApplicationContext 를 사용한다. //appConfig.xml 파일을 통해 스프링 컨테이너에 빈 설정 정보 전달 ApplicationContext ac = new..

플러시 (Flush) 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 기능을 한다. 트랜잭션이 커밋될 때, 플러시가 동작해 쓰기 지연 SQL 저장소에 쌓아뒀던 쿼리들을 데이터베이스에 전송한다. 즉, 영속성 컨텍스트와 데이터베이스를 동기화하는 작업이다. ※ 플러시가 발생해도 1차 캐시 안의 내용은 삭제되지 않는다. 직접 호출 (em.flush()) //영속 상태인 member 엔티티 Member member = new Member(200L, "A"); em.persist(member); //플러시를 직접 호출하면 쿼리가 플러시 호출 시점에 전송됨 em.flush(); transaction.commit(); JPQL 쿼리 실행 시 호출 JPQL 쿼리를 실행하는 다음 코드를 보자. em.pers..

1차 캐시 (First Level Cache) 1차 캐시는 영속성 컨텍스트 내에 존재하는 캐시이다. 영속성 컨텍스트에 엔티티가 저장되는 순간, 1차 캐시에 다음과 같은 형태로 저장된다. { key : @Id로 선언한 필드 값, value : 해당 엔티티 } find()가 호출되는 순간, EntityManager 내부의 이 1차 캐시를 먼저 탐색하게 된다. 이 때, 찾는 엔티티를 발견했다면 즉시 반환한다. 만약 1차 캐시에 해당 엔티티가 존재하지 않는다면, 데이터베이스에서 조회한다. ※ 1차 캐시는 Global하지 않다. 즉, 영속성 컨텍스트끼리 이 1차 캐시를 공유하지 않는다. 객체의 동일성 보장 영속성 컨텍스트는 영속 상태의 엔티티들에 대한 동일성(Identity)을 보장한다. 1차 캐시에 의해, me..

영속성 컨텍스트 (Persistence Context) 영속성 컨텍스트는 JPA에서 매우 중요한 개념으로, 엔티티를 영구 저장하는 환경이라는 의미를 가진다. 영속성 컨텍스트는 논리적인 개념이다. 즉 실제로 존재하는 개념이 아니며, 우리는 코드 내에서 영속성 컨텍스트에 EntityManager을 통해 접근한다. JPA는 매 요청마다 EntityManagerFactory에서 EntityManager를 생성한다. 이렇게 생성된 EntityManager는 내부적으로 DB 커넥션 풀을 사용해 데이터베이스와 연동된다. 스프링에서 EntityManager를 주입받아 사용할 때, 같은 트랜잭션 범위의 EntityManager들은 동일 영속성 컨텍스트에 접근한다. 엔티티의 생명주기 (Entity Lifecycle) 비영..

상속관계 매핑 객체는 상속관계가 존재하지만, 관계형 데이터베이스는 대부분 상속 관계가 존재하지 않는다. 하지만 관계형 데이터베이스의 슈퍼/서브타입 모델링 기법이 객체의 상속 관계와 꽤 유사하다. 우리는 이를 이용해 객체의 상속 구조를 매핑할 수 있다. 상속 관계를 매핑하는 방법은 다음과 같다. @Entity @Inheritance(strategy = InheritanceType.XXX) // 상속전략 선택 public class Item { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private int price; } @Entity public class Album extends..

static 키워드 JAVA에서 static 키워드는 메모리에 한 번 할당된 후, 프로그램 종료 시점까지 해제되지 않음을 의미한다. static 키워드가 붙은 변수나 메소드는 각 객체(인스턴스)에 속하지 않고, 클래스 자체에 고정된다. 이러한 필드나 메소드를 통틀어 정적 멤버라 한다. 즉, 정적 멤버들은 위 그림에서 static 영역에 할당되어, 모든 객체가 공유해 어디서든 참조할 수 있다는 특징을 갖는다. 하지만 static 영역은 Garbage Collector의 관리 영역에 포함되지 않기 때문에, 프로그램 종료 시까지 메모리가 할당된 상태로 유지된다. 따라서 무분별한 사용은 좋지 않다. ※ Garbage Collector : 메모리 관리 기법 중 하나로, 프로그램이 동적으로 할당한 메모리 영역 중 ..

MVC 패턴 MVC 패턴은 소프트웨어 디자인 패턴 중 하나로, 사용자 인터페이스와 비즈니스 로직을 분리해 두 영역을 서로 영향 없이 수정할 수 있도록 하여 유지보수성을 높이는 장점을 가진다. 일반적으로 웹 애플리케이션 서비스에서 MVC 패턴은 다음 그림과 같이 구성된다. M : 모델 (Model) 모델은 프로그램의 도메인 및 어플리케이션의 정보, 데이터에 대응한다. 예를 들어 상품 주문 서비스를 개발한다고 했을 때, 이를 개발하기 위해 필요한 회원, 상품, 주문 등의 도메인들이 이에 해당한다. 이러한 도메인들의 실제 데이터의 가공을 담당하는 컴포넌트들도 포함한다. 모델은 뷰나 컨트롤러에 대한 어떠한 정보도 알 필요가 없다. 이는 곧 데이터 변경이 일어났을 때 모델에서 뷰를 참조하는 속성을 가지면 안 된다..

인터페이스 (Interface) 인터페이스(Interface)란, 추상 메소드(Abstract Method)만으로 이루어진 클래스이다. 추상 메소드는 구현 내용 없이 선언만 해 놓는 형태로 정의된다. 즉, 인터페이스 내의 모든 메소드는 선언만 되어 있을 뿐, 그 내용은 없다. public interface Car{ //인터페이스 내의 변수는 반드시 static final로 지정한다. public static final int variable = 10; //인터페이스 내에서 지정한 메소드는 //반드시 이 인터페이스를 구현하는 클래스가 구현해야 한다. //즉, 클래스에게 특정 메소드들을 구현하도록 강제할 수 있다. public void Ride(); public void RideReverse(); publi..

이번 포스팅에서는 다양한 연관관계들과, 그 연관관계를 JPA에서 어떻게 표현하는지 알아보자. 다대일 관계 (ManyToOne) 가장 많이 사용되기 때문에 꼭 알아야 하는 연관관계이다. 앞선 포스팅에서 살펴본 예시로, Member와 Team의 관계가 이에 해당한다. Member는 하나의 Team만 가질 수 있고, Team은 다수의 Member를 가질 수 있기 때문에, 이는 Member 입장에서 다대일 관계에 해당한다. @Entity public class Member{ @Id @GeneratedValue private Long id; @Column(name = "USERNAME") private String name; private int age; //연관관계 설정 : 멤버 입장에서 다대일 매핑 @Many..