minmin_key.log

값 타입 - 불변 객체, 컬렉션

Tue, 31 Aug 2021 07:26:13 GMT

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하기 위한 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 부작용(side effect)가 발생할 수 있다 위 그림과 같이 회원1은 OldCity를 멤버로 가지고 있지만 회원2도 city를 참조하게 되어 NewCity로 바꾸면 회원1의 멤버도 바뀌는 부작용이 발생한다.

값 타입 복사

값 타입의 실제 인스턴스 값을 공유하는 것은 위험하기 때문에 값(인스턴스)를 복사해서 사용해야 한다.

객체 타입의 한계

항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
자바 기본 타입에 값을 대입하면 값을 복사히지만 객체 타입은 참조 값을 직접 대입하고 이것을 막을 방법이 없다.
객체의 공유 참조는 피할 수 없다.

불변 객체

객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단할 수 있다.
값 타입은 불변 객체(immutable object)로 설계해야 한다.
불변객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 된다.

Integer, String은 자바에서 제공하는 대표적인 불변 객체이다.

값 타입의 비교

값 타입 : 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 한다.

int a = 10;
int b = 10;
// a == b -> true

Address a = new Address("서울시");
Address b = new Address("서울시");
// a == b -> false;

동일성(identity) 비교 : 인스턴스의 참조 값을 비교, ==사용
동등성(equivalence) 비교 : 인스턴스의 값을 비교, equals()사용
값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야한다. 이때 값 타입의 equals() 메소드를 적절하게 재정의해야 한다. (주로 모든 필드 사용)

값 타입 컬렉션

값 타입을 컬렉션(Set, List 등)으로 가지는 것을 말한다. 이때 엔티티 내에서는 문제가 없지만 DB로 구현할 때 문제가 생긴다. 관계형 데이터베이스는 컬렉션을 테이블 안에 담을 수 있는 구조가 없다. 따라서 위 그림과 같이 컬렉션을 별도의 테이블로 나누어 관리하여 일대다 관계로 테이블을 구성해야 한다.

값 타입 컬렉션

값 타입을 하나 이상 저장할 때 사용
데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없기 때문에 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.
@ElementCollection, @CollectionTable 사용

값 타입 컬렉션의 제약사항

값 타입은 엔티티와 다르게 식별자 개념이 없다. 따라서 값을 변경하면 추적이 어렵다.
값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현제 값을 모두 다시 저장한다.
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럽을 묶어서 기본키를 구성해야한다. -> null 입력 불가, 중복 저장 불가

값 타입 컬렉션의 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려해야 하낟.
일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용한다.
영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션처럼 사용하자.

정리

엔티티 타입의 특징

식별자 존재
생명 주기 관리
공유
값 타입의 특징
식별자 없음
생명 주기를 엔티티에 의존
공유하지 않는 것이 안전 (복사해서 사용)
불변 객체로 만드는 것이 안전
값 타입은 정말 값 타입이라 판단될 때만 사용하자!

엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안된다!

식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 값 타입이 아닌 엔티티를 사용하자!!

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

값 타입 - 기본값, 임베디드 타입

Mon, 30 Aug 2021 07:20:51 GMT

JPA의 데이터 타입 분류

엔티티 타입

@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속해서 추적 가능하다. (Ex. 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능)

값 타입

int, Integer, String과 같이 단순히 값으로 사용하는 자바 기본 타입이나 객체를 말한다.
식별자가 없고 값만 있으므로 변경시 추적이 불가능하다. (Ex. 숫자 100을 200으로 변경하면 완전히 다른 값이 된다.)

값 타입 분류

기본값 타입
- 자바 기본 타입(int, double)
- 래퍼 클래스(Integer, Long)
- String
- 임베디드 타입(Embedded Type, 복합 값 타입)
컬렉션 값 타입(Collection Value Type)

기본값 타입

Ex. String name, int age 등
생명주기를 엔티티에 의존한다. (Ex. 회원을 삭제하면 이름, 나이 등 필드들도 함께 삭제된다.)
값 타입을 공유하면 안 된다! (Ex. 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안된다.)

참고. 자바의 기본 타입은 절대 공유되지 않는다.

int, double과 같은 기본 타입(primitive type)은 항상 값을 복사하기 때문에 절대 공유되지 않는다. 하지만 Integer 같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경되지 않는다.

임베디드 타입 (복합 값 타입)

임베디드 타입

새로운 값 타입을 직접 정의할 수 잇다.
JPA는 임베디드 타입(embedded type)이라 한다.
주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 한다.
int, String과 같은 값 타입이기 때문에 변경하면 추적할 수 없다.

임베디드 타입 예시

회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편 번호를 가진다.
회원 엔티티의 근무 시작일, 근무 종료일은 근무 기간으로, 주소들은 집 주소로 묶을 수 있을 것이다.
따라서 Period와 Address라는 클래스를 만들어 연결해주면 재사용성과 편의가 향상될 것이다.

사용법

@Embeddable : 값 타입을 정의 하는 곳에 표시 (값 타입 정의 시 기본 생성자는 필수이다.)

@Embedded : 값 타입을 사용하는 곳에 표시

    //값 타입 사용
    @Entity
    public class Member {
      ...
      @Embedded
      private Period workPeriod;
    }    

    ~~~~~~~~~~~~~~~~~~~~~~~~

    //값 타입 정의
    @Embeddable
    public class Period {
      private Date startDate;
      private Date endDate;
      //기본 생성자 필수
      public Period(...) { ... }
      //내부 메서드 사용 가능
      public boolean isWork() { ... }
    }

임베디드 타입의 장점

재사용성
높은 응집도
Period.isWork()과 같이 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다. 이를 통해 더욱 객체 지향적으로 프로그래밍이 가능하다.
임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티의 생명주기에 의존한다.

임베디드 타입과 테이블 매핑

임베디드 타입은 엔티티의 값일 뿐이다.
임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능하다.
잘 설계한 ORM 어플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

@AttributeOverride : 속성 재정의

한 엔티티 내에서 같은 값 타입을 사용하면 Column 명이 중복될 것이다. 이때 @AttributeOverride를 통해 Column 명 속성을 재정의하여 해결할 수 있다.

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

프록시와 연관관계 관리

Thu, 26 Aug 2021 08:17:53 GMT

프록시

프록시 조회 : em.getReference() 를 통해 데이터 베이스 조회를 미루는 가짜(프록시) Entity 객체를 조회한다. (데이터 베이스를 통한 실제 Entity 객체 조회는 em.find())
프록시 객체
실제 클래스를 상속 받아서 만들어진다. 따라서 실제 클래스와 겉 모양이 같다.
프록시 객체는 실제 객체의 참조(target) 을 보관한다. 따라서 프록시 객체를 호출하면 참조(target)에 있는 실제 객체의 메소드를 대신 호출해 준다.

프록시 객체의 초기화

초기화 과정

//프록시 객체 조회
Member member = em.getReference(Member.class, "id1");
member.getName();

위 코드가 실행되면 다음과 같은 과정이 진행된다.

Client가 프록시 객체의 메소드를 요청한다.
아직 프록시 객체는 초기화 되지 않아 프록시 객체 내의 target이 없기 때문에 JPA가 영속성 컨텍스트에 실제 객체를 가져오도록 초기화를 요청한다.
영속성 컨텍스트는 DB를 조회해서 원하는 실제 객체를 조회한다.
실제 객체를 생성한다.
target이 실제 객체와 연결되어 target.getName()을 실행할 수 있게 된다.

프록시의 특징

프록시 객체는 처음 사용할 때 한 번만 초기화된다.
프록시 객체를 초기화 할 때, 프록시 객체가 실제 Entity로 바뀌는 것이 아니라 프록시 객체를 통해 실제 Entity에 접근 가능하다.
프록시 객체는 원본 Entity를 상속받기 때문에 타입 체크시 주의해야한다. (== 비교는 실패하기 때문에 instanceof를 사용하자)
영속성 컨텍스트에 찾는 Entity가 이미 있으면 em.getReference()를 호출해도 실제 Entity를 반환한다. (이미 영속성 컨텍스트에 있기 때문에 프록시로 반환해봐야 이점이 없고, JPA는 같은 영속성 컨텍스트에서 가져오고 PK가 같으면 항상 같은 것을 반환해주는 것을 보장해주기 때문이다. 이러한 원칙 때문에 em.getReference()를 먼저 호출하고 em.find()를 호출하면 em.find()에도 프록시 객체를 반환한다.)
영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생한다. (org.hibernate.LazyInitializationException 예외를 터트림)

프록시 확인

프록시 인스턴스의 초기화 여부 확인 PersistenceUnitUtil.isLoaded(Object entity)
프록시 클래스 확인 방법 entity.getClass().getName() 출력
프록시 강제 초기화 org.hibernate.Hibernate.initialize(entity);

즉시 로딩과 지연 로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

단순히 member 정보만 사용하는 비지니스 로직일 경우 member를 조회 할 때 team도 같이 조회하게 된다면 불필요한 cost가 발생한다. 이때 team을 프록시로 조회하게 된다면 DB에 접근하는 cost를 줄일 수 있을 것이다.

지연 로딩 LAZY를 사용해서 프록시로 조회

@Entity
public class Member {
  ...
  @ManyToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}

내부 메커니즘 Member member = em.find(Member.class, 1L); Member를 부를 때 Team은 프록시 객체로 생성된다. team.getName(); 이 코드와 같이 실제 team을 사용하는 시점에 DB를 조회하여 프록시 객체가 초기화 된다.

즉시 로딩 EAGER를 사용해서 함께 조회

만약 Member와 Team이 모두 필요한 경우 지연 로딩을 사용하면 네트워크를 2번 따로 접근하기 때문에 오히려 cost가 증가한다. 이럴 경우는 EAGER를 사용해서 Member와 Team을 함께 실제 객체로 조회하는 것이 이득일 것이다.

@Entity
public class Member {
  ...
  @ManyToOne(fetch = FetchType.EAGER)
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}

내부 메커니즘 Member를 로딩할 때 조인하여 Team까지 같이 조회한다. JPA 구현체는 가능하면 조인을 사용해서 SQL 한번에 함께 조회한다.

프록시와 즉시 로딩 주의점

가급적 지연 로딩만 사용하자 (특히 실무에서)
즉시 로딩을 적용하면 예상하지 못한 SQL이 발생한다.
즉시 로딩은 JPQL에서 N+1 문제를 일으킨다. 아래 코드가 실행 되면 JPQL은 SQL로 번역되어 실행된다. 아래 SQL이 그대로 실행되면서 Member만 조회하게 되고, Member를 조회하면서 EAGER이기 때문에 Team을 조회하는 SQL이 추가적으로 실행된다. 이때 다른 Team일 경우 영속성 컨텍스트에 없기 때문에 추가적으로 조회하게 된다. 따라서 1개의 select문이 10개의 Member를 조회하게 되면 Team을 조회하는 SQL이 10번 실행되게 된다. 이처럼 1개의 select문이 N개의 select문을 추가로 부르기 때문에 N+1 문제라고 한다.
```
List members = em.createQuery("select m from Member m", Member.class)
  .getResultList();
```
이 문제를 해결하기 위해서는 LAZY로 변경한 후 fetch join을 사용해서 해결할 수 있다.
```
List members = em.createQuery("select m from Member m join fetch m.team", Member.class)
  .getResultList();
```
@ManyToOne, @OneToOne 즉시 로딩이 Default이다. 따라서 LAZY로 변경해 줘야 한다.
@OneToMany, @ManyToMany는 지연 로딩이 Default이다.

지연 로딩 활용 - 실무

모든 연관관계에 지연 로딩을 사용하자!!
실무에서 즉시 로딩을 사용하지 말자!!
JPQL fetch 조인이나, Entity 그래프 기능을 사용하자!!
즉시 로딩은 상상하지 못한 쿼리가 나가게 된다.

영속성 전이 : CASCADE

CASCADE

연관 관계나 즉시 로딩, 지연 로딩과 전혀 상관이 없다.
특정 Entity를 영속 상태로 만들 때 연관된 Entity도 함께 영속 상태로 만들고 싶을 때 사용한다. (Ex. parent Entity를 저장할 때 child Entity도 저장하고 싶을 때)

주의점

영속성 전이는 연관관계 매핑이나, 즉시 로딩, 지연 로딩과 전혀 관련이 없다.
단지 Entity를 영속화할 때 연관된 Entity도 함께 영속화하는 편리함을 제공할 뿐이다.
하위 Entity가 하나의 상위 Entity(단일 소유자)에만 연관되어 있다면 사용할 수 있다. 하지만 여러 상위 Entity와 연관되어 있다면 CASCADE사용하면 운영이 매우 힘들어지므로 사용하지 않는 것이 좋다.

CASCADE의 종류

ALL : 모두 적용
PERSIST : 영속만
REMOVE : 삭제만
MERGE, REFRESH, DETACH

고아 객체

고아 객체 제거 : 부모 Entity와 연관 관계가 끊어진 자식 Entity를 자동으로 삭제하는 기능이다.
orphanRemoval = true

자식 Entity를 컬렉션에서 제거하면 자동으로 DB에 DELETE 쿼리가 나가서 DB에서도 삭제된다.

Parent parent1 = em.find(Parent.class, id);
parent1.getChildren().remove(0);
//자식 Entity를 제거 -> DELETE 쿼리 전송

주의점

참조가 제거된 Entity는 다른 곳에서 참조하지 안흔ㄴ 고아 객체로 보고 삭제하는 기능이다.
참조하는 곳이 하나일 때 사용해야 한다. 즉 특정 Entity가 단일 소유할 때 사용해야 한다.
@OneToOne, @OneToMany만 사용 가능하다.
부모를 제거하면 자식은 고아가 된다. 따라서 고아 객체 제거 기능을 활성화하면, 부모를 제거할 때 자식도 함께 제거된다. 이것은 CascadeType.REMOVE처럼 동작한다.

영속성 전이 + 고아 객체, 생명 주기

CascadeType.ALL + orphanRemovel=true
스스로 생명주기를 관리하는 Entity는 em.persist()로 영속화, em.remove()로 제거한다.
두 옵션을 모두 활성화하면 부모 Entity를 통해서 자식의 생명 주기를 관리할 수 있다.
도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용한다.

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

@MappedSuperclass

Thu, 26 Aug 2021 05:54:25 GMT

@MappedSuperclass

공통 매핑 정보가 필요할 때 사용한다. 이때 DB 상에서는 서로 연관이 없으나 공통되는 속성이 존재할 때 편의를 위해 사용한다.
상속 관계 매핑이 아니다.
엔티디가 아니고, 테이블과 매핑하지 않는다.
부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공한다. (@Entity 클래스는 Entity나 @MappedSuperclass로 지정한 클래스만 상속 가능하다.)
조회, 검색 불가하다. (em.find(BaseEntity) 불가)
직접 생성해서 사용할 일이 없으므로 추상 클래스를 권장한다.

코드 구현

@MappedSuperclass
public class BaseEntity {
private Long id;
private String name;
}

...

@Entity public class Member extends BaseEntity { ... }

```

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

다양한 연관관계 매핑

Mon, 23 Aug 2021 06:54:55 GMT

연관관계 매핑시 고려사항 3가지

다중성

다대일 : @ManyToOne
일대다 : @OneToMany
일대일 : @OneToOne
다대다 : @ManyToMany (실무에선 '다대다' 관계는 쓰면 안 된다!)

단방향, 양방향

테이블
- 외래 키 하나로 양쪽 조인 가능
- 사실 방향이라는 개념이 없다. 즉 단방향과 양방향이 동일하다.
객체
- 참조용 필드가 있는 쪽으로만 참조 가능
- 한쪽만 참조하면 단방향
- 양쪽이 서로 참조하면 양방향 (양방향 = 단방향 2개)

연관관계의 주인

테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음
객체 양방향 관계는 A->B, B->A처럼 참조가 2개이다.
참조가 2개이므로 둘중 테이블의 외래 키를 관리할 곳을 지정해야 한다.
연관관계의 주인 : 외래 키를 관리하는 참조
주인의 반대편 : 외래 키에 영향을 주지 않는다. 단순 조회만 가능하다.

다대일 [N:1]

다대일 단방향

다대일(N:1)에서 항상 다(N) 쪽에 외래키가 존재한다. 가장 많이 사용하는 연관관계이고, 반대는 일대다 [1:N] 관계이다.

다대일 양방향

외래 키가 있는 쪽이 연관관계의 주인이다. 양쪽이 서로 참조하도록 객체를 설계하고, 테이블 관점에서는 단방향과 차이가 없다.

일대다 [1:N]

일대다 단방향

먼저 아래 그림을 보면 다대일과 테이블 구조는 동일하다.
객체의 일대다(1:N)에서 일(1)이 연관관계의 주인이지만 테이블에서는 다(N) 쪽에 외래 키가 있다.
객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조이다.
@JoinColumn을 꼭 사용해야 한다. 그렇지 않으면 조인 테이블 방식을 사용한다. (중간에 테이블을 하나 추가함)
일대다 단방향의 단점
- 코드가 직관적이지 않다. (Team을 고쳐도 Member 테이블이 Update되는 등)
- 연관관계 관리를 위해 추가로 UPDATE SQL 실해
일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자!

일대다 양방향

읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법이다.
@JoinColumn(insertable=false, updatable=false)를 이용해서 읽기 전용 필드로 만든다.
- 깔끔하게 다대일 양방향을 사용하자!

일대일 [1:1]

일대일 관계

일대일 관게는 그 반대도 일대일이다.
주 테이블이나 대상 테이블 중에 외래 키 선택 가능하다.
외래 키에 데이터베이스 유니크(UNI) 제약 조건을 추가해야 한다.

일대일 : 주 테이블에 외래 키 단방향, 양방향

단방향
양방향 다대일과 같이 작성하고, 반대편에 mappedBy를 적용하면 된다.

일대일 : 대상 테이블에 외래 키 단방향, 양방향

단방향 : JPA에서 지원하지 않는다.
양방향 : 일대일 주 테이블 양방향 매핑 방법과 동일하다.

다대다 [N:M]

다대다

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
연결 테이블을 추가해서 일대다, 다대일 관계로 풀어야 한다.
객체는 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능하다. (Ex. Member는 Product List, Product는 Member List로 참조 가능)
@JoinTable로 연결 테이블을 지정할 수 있다.

다대다 매핑의 한계

편리해 보이지만 실무에서 사용 X
연결 테이블이 단순히 연결만 하고 끝나는 것이 아니라 추가적으로 주문시간, 수량과 같은 데이터가 들어올 수 있다. 또한 의도하지 않은 Query가 추가될 수 있다.

한계 극복

연결 테이블용 Entity를 추가 (연결 테이블을 Entity로 승격)
@ManyToMany -> @OneToMany, @ManyToOne

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

연관관계 매핑 기초 - 양방향 연관관계

Sat, 21 Aug 2021 05:30:19 GMT

양방향 연관관계와 연관관계의 주인

양방향 매핑

모델링 아래 그림을 보면 객체에서 양방향으로 연관관계를 설정해도 테이블은 단방향과 차이점이 없다. 즉 테이블에서는 방향이라는 개념 없이 외래 키를 이용해서 조인하여 서로의 연관관계를 알 수 있다. 하지만 객체에서 Team이 Member를 참조하기 위해서는 Member의 list가 Team 객체 내에 존재해야 한다.

양방향 연관관계 코드 Member의 경우 단방향과 동일하다.

@Entity
  public class Member {
  ...
  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}

Team에서는 List를 통해 Member를 참조하게 되고, 이때 mappedBy = "team"을 통해 Member 객체 내의 Team team과 매핑을 해줄 수 있다.

@Entity
public class Team {
 ...
 @OneToMany(mappedBy = "team")
 List members = new ArrayList();
 ...
}

이를 통해 아래 코드와 같이 Team에서도 Member를 조회할 수 있다.

//조회
Team findTeam = em.find(Team.class, team.getId());
Member findMember = em.find(Member.class, member.getId());

//Team으로부터 Member정보 조회 int memberSize = findTeam.getMember().size(); //Member로부터 Team을 조회 후 Team에 속한 모든 Member조회 List members = findMember.getTeam().getMembers();


### 연관관계의 주인과 mappedBy
#### 객체와 테이블이 관계를 맺는 차이
   + 객체 연관관계 = 2개
       - 회원 -> 팀 연관관계 (단방향)
       - 팀 -> 회원 연관관계 (단방향)
   + 테이블 연관관계 = 1개
       - 회원 <-> 연관관계 (양방향)
+ 객체의 양방향 연관관계
객체의 **양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.** 즉 객체를 양방향을 참조하려면 **단방향 연관관계를 2개** 만들어야 한다.

+ 테이블의 양방향 연관관계
테이블은 **외래 키 하나**로 두 테이블의 연관관계를 관리한다. 즉 **양쪽으로 조인**할 수 있다.

+ 외래 키 관리
객체 관점에서는 2개의 단방향 연관관계가 존재하지만 테이블 상에서는 하나의 외래 키만 존재한다. 따라서 2개의 연관관계 중 하나가 이 외래 키를 관리해야 한다.
![](https://images.velog.io/images/minmin_key/post/e0adc992-132b-4038-9ece-7957eaf0fae6/image.png)

#### 연관관계의 주인
+ 양방향 매핑 규칙
  - 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
  - **연관관계의 주인만이 외래키를 관리(등록, 수정)**
  - **주인이 아닌 쪽은 읽기만 가능**
  - 주인은 mappedBy 속성 사용 X
  - 주인이 아니면 mappedBy 속성으로 주인 지정
+ 주인은 무엇으로?
  **외래 키가 있는 곳을 주인**으로 정한다. 아래 그림의 경우 Member 테이블에 외래 키가 존재하므로 Member 객체가 연관 관계의 주인이 된다.
   ![](https://images.velog.io/images/minmin_key/post/974511f3-506f-4610-969b-2eebb82b8f5e/image.png)
   연관관계의 주인은 비지니스 적으로 중요한 것이 아닌 설계 상에서 유리한 곳을 주인으로 하는 것이 정석이다.

#### 양방향 매핑 시 주의점
+ 연관관계의 주인에 값을 입력하지 않는 경우
아래 코드와 같이 연관관계의 주인에 값을 입력하지 않을 경우 Member 테이블은 Team을 참조하지 못했으므로 null 값만 존재하게 된다.
```java
  Team team = new Team();
  team.setName("TeamA");
  em.persist(team);

  Member member = new Member();
  member.setName("member1");

  //역방향(주인이 아닌 방향)만 연관관계 설정
  team.getMembers().add(member);

  em. persist(member);

따라서 반드시 주인에 값을 입력해야 하고, 순수한 객체 관계를 고려해서 항상 양쪽 모두 값을 입력해야 한다.

  ...
  //연관관계의 주인인 member에 값 설정
  member.setTeam(team);
  //team에도 연관관계 설정
  team.getMembers().add(member);
  ...

연관관계 편의 메소드를 생성하자.
양방향 매핑 시에 무한 루프를 조심하자. Ex) toString(), lombok(되도록이면 toString 쓰지 말자), JSON 생성 라이브러리(Controller에서 Entity를 반환하지 말자!, DTO로 변환하여 반환하자)

양방향 매핑 정리

단방향 매핑만으로도 이미 연관관계 매핑은 완료 즉 JPA에서 객체와 테이블 설계는 단방향으로도 완료되어야 한다.
양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐이다.
JPQL에서 역방향으로 탐색할 일이 많다.
따라서 단방향 매핑을 잘 해두면 양방향은 필요할 때 추가해도 된다. 이때 테이블에는 영향을 주지 않는다.
연관관게의 주인은 외래 키의 위치를 기준으로 정해야 한다. 비지니스 로직을 기준으로 주인을 선택하면 안된다.

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

연관 관계 매핑 기초 - 단방향 연관 관계

Thu, 19 Aug 2021 12:55:18 GMT

연관 관계가 필요한 이유

객체를 테이블에 맞추어 모델링

예제 시나리오
- 회원과 팀이 있다.
- 회원은 하나의 팀에만 소속될 수 있다.
- 회원과 팀은 다대일 관계이다.
객체를 테이블에 맞추어 모델링하며 연관관계가 없는 경우 위 그림과 같이 MEMBER 테이블은 TEAM 테이블의 TEAM_ID를 FK로 가져와 연관관계가 존재하지만 객체에서는 서로 연관 관계가 존재하지 않는다.

Entity 구현 Member 객체는 Team의 id를 외래키로 가져올 때 참조하는 것 대신 외래키를 그대로 사용하였다.

@Entity
public class Member {
  @Id @GeneratedValue
  private Long id;

  @Column(name = "USERNAME")
  private String name;

  @Column(name = "TEAM_ID")
  private Long teamId; 
  … 
}

@Entity
public class Team {
  @Id @GeneratedValue
  private Long id;

  private String name; 
  … 
}


+ 객체 지향적이지 않다.
Member 객체에 Team의 id를 설정하기 위해서는 Team 객체에서 id 값을 얻어와 직접 주입해주어야 한다.
```java
 //팀저장
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 //회원 저장
 Member member = new Member();
 member.setName("member1");
 //team의 id를 가져와 직접 주입
 member.setTeamId(team.getId());
 em.persist(member);
 //팀저장
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 //회원 저장
 Member member = new Member();
 member.setName("member1");
 //team의 id를 가져와 직접 주입
 member.setTeamId(team.getId());
 em.persist(member);

Member와 Team을 조회하는 경우에도 Member와 Team을 각각 식별자로 조회해야한다.

 //조회
 Member findMember = em.find(Member.class, member.getId()); 
 //연관관계가 없음
 Team findTeam = em.find(Team.class, team.getId());

객체를 테이블에 맞추어 데이터 중심으로 모델링하는 경우 협력 관계를 만들 수 없다.
- 테이블은 외래 키로 조인하여 연관된 테이블을 찾는다.
- 객체는 참조를 사용해서 연관된 객체를 찾는다
- 이렇듯 객체와 테이블 사이에는 큰 차이점이 있다.
  
  단방향 연관 관계
  
  객체 지향 모델링
- 객체의 연관 관계를 사용해서 모델링 하는 경우 Member 객체는 Team의 id가 아닌 Team 그 자체를 참조를 통해 연관 관계가 형성되어 있다. 코드로 보면 아래와 같이 @ManyToOne을 통해 다대일 관계를 형성한다.
```
@Entity
public class Member {
@Id @GeneratedValue
private Long id;

@Column(name = "USERNAME")
private String name;
private int age;

@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
}
```
- 객체 지향적이다. Member에 Team을 설정해줄 때도 바로 Team을 주입해준다. 다른 Team을 주입하고자 할 때도 마찬가지로 간단하게 가능하다.
```
//팀 저장
Team team = new Team();
team.setName("TeamA");
em.persist(team);
```
//회원 저장 Member member = new Member(); member.setName("member1"); member.setTeam(team); //단방향 연관관계 설정, 참조 저장 em.persist(member);
```
또한 조회를 해줄 때에도 Member 객체에서 바로 Team을 조회 가능하다.
```java
//조회
Member findMember = em.find(Member.class, member.getId()); 
//참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();
```

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

Entity 매핑

Thu, 19 Aug 2021 02:11:57 GMT

객체와 테이블 매핑 : @Entity, @Table

@Entity

@Entity가 붙은 클래스는 JPA가 관리하고, Entity라 한다.
JPA를 사용해서 테이블과 매핑할 클래스는 @Entity를 필수로 사용한다.
주의!
- 기본 생성자 필수 (파라미터가 없는 public 또는 protected 생성자)
- final 클래스, enum, interface, inner 클래스 사용 X
- DB에 저장할 필드에 final 사용 X

@Table

Entity와 매핑할 테이블을 지정한다.

DB 스키마 자동 생성

DDL을 애플리케이션 실행 시점에 자동 생성
테이블 중심 -> 객체 중심
DB 방언을 활용해서 DB에 맞는 적절한 DDL 생성
이렇게 생성된 DDL은 개발 단계에서만 사용
이후 운영에서는 이 DDL을 사용하지 않거나, 적절히 다듬어서 사용
생성 방법 : hibernate.hbm2ddl.auto
속성
주의점!
운영 장비에는 절대 create, create-drop, update를 사용해선 안된다!!
개발 초기 단계 : create 또는 update
테스트 서버 : update 또는 validate (여러 사람이 함께 테스트 혹은 개발할 때 create 사용시 기록이 모두 날아감)
스테이징과 운영 서버 : validate 또는 none (되도록이면 사용하지 말자! alter를 잘못 입력될 경우 시스템 마비될수도...)

DDL 생성 기능

제약 조건 추가, 유니크 제약 조건 추가 등 ex) 회원 이름 : 필수, 10자 초과X @Column(nullable = false, length = 10)
DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고, JPA의 실행 로직에는 영향을 주지 않는다.

필드와 Column 매핑

매핑 어노테이션 정리

@Column

@Enumerated

자바 enum 타입을 매핑할 때 시용
속성
- EnumType.ORDINAL : enum 순서를 DB에 저장, 사용 X (유지보수 어려움)
- EnumType.STRING : enum 이름을 DB에 저장
- Defalut : EnumType.ORDINAL

@Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용
최근에는 생략 가능하다.

@Lob

지정 가능한 속성이 없다.
매핑하는 필드의 타입이 문자면 CLOB, 나머지는 BLOB 매핑

@Transient

필드에 매핑하지 않을 경우 사용
DB에 저장 X, 조회 X
주로 메모리상에서만 임시로 값을 보관하고 싶을 때 사용한다.

기본 키 매핑

기본 키 매핑 방법

직접 할당 : @Id 사용
자동 생성 : @GeneratedValue

@GeneratedValue 전략

IDENTITY
- 기본 키 생성을 DB에 위임
- JPA는 Persistence Context에서 Entity를 관리하기 위해 기본 키가 필요하다. 하지만 IDENTITY는 DB에 들어가고 나서야 기본 키를 알 수 있기 때문에 예외적으로 em.commit() 시점이 아닌 em.persist() 시점에 DB에 INSERT SQL이 실해되고, DB에서 기본키를 조회하여 Persistence Context의 1차 캐시에 추가된다.
SEQUENCE
- DB의 Sequence Object라는 유일한 값을 순서대로 생성하는 특별한 DB Object를 사용한다.
- 테이블마다 Sequence를 따로 관리하기 위해서 @SequenceGenerator로 매핑할 수 있다. (이때 allocationSize는 Sequence가 한번 호출될 때 증가하는 수로 Default가 50이다. 이것을 통해 성능 최적화가 이루어 질 수 있다.)
  - 성능 최적화 SEQUENCE 전략은 다음 키 값이 무엇인지 받기 위해 매번 DB서버와 통신을 해야한다. 이것을 allocationSize를 통해 성능 최적화를 할 수 있다. 만약 allocationSize가 50이라면 처음 DB서버와 통신할 때 현재 키 값은 1이고, 다음 키 값은 51로 설정하게 된다. 이후 50번 키까지는 DB서버와 통신 없이 1~50까지 순서대로 배정이 되고, 51번째 키를 받아야 하는 순간 다시 DB서버와 통신하여 100번까지의 키를 할당 받게 된다. 이러한 방법을 통해 DB서버와의 통신을 줄여 성능을 최적화한다.
TABLE
- 키 생성 전용 테이블을 만들어 DB의 Sequence를 횽내내는 전략
- 장점 : 모든 DB에 적용 가능
- 단점 : 성능이 떨어진다.
- 테이블 생성
- TableGenerator
  권장하는 식별자 전략
기본 키 제약 조건 : null X, 유일, 변하면 안된다.
미래까지 '변하지 않는다'를 만족하는 자연키를 찾기는 어렵다. 따라서 대체키를 사용하자.
권장 : Long형 + 대체키 + 키 생성전략 사용 (AUTO, Sequence Object 등)

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

JPA Persistence Context

Mon, 16 Aug 2021 14:38:34 GMT

Entity Manger Factory, Entity Manger

아래 그림과 같이 웹 어플리케이션은 EntityManber Factory는 고객의 요청에 따라 EntityManager를 생성한다. 이 EntityManager는 Connection을 통해 DB에 접근하게 된다.

Persistence Context

Persistence Context : Entity를 영구 저장하는 환경이다.
Persistence Context는 논리적인 개념으로 Entity Manager를 통해 접근 가능하다. 따라서 Entity Manager가 생성될 때 Persistence Context도 생성되어 Mapping된다.

Entity의 생명 주기

비영속(new/transient) : Persistence Context와 관계없는 새로운 상태
영속(managed) : Persistence Context에 관리되는 상태
준영속(detached) : Persistence Context에 저장되었다가 분리된 상태
삭제(removed) : 삭제된 상태

비영속 상태

객체가 생성만 되고 Persistence Context에 저장되지 않은 상태이다.

//객체 생성
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

영속 상태

생석된 객체가 Persistence Context에 저장된 상태. 하지만 이때 DB에 저장되는 것은 아니다 DB에 저장되는 시점은 Transaction에 Commit되는 시점이다.

...
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
//객체를 저장
em.persist(member);

준영속과 삭제

준영속은 객체를 Persistence Context에서 분리시킨 상태이고, 삭제는 말 그대로 삭제된 상태이다.

...
//객체 분리
em.detach(member);

//객체 삭제
em.remove(member);

Persistence Context의 이점

1. 1차 캐시

Entity Manager가 조회를 요청할 때 먼저 Persistence Context의 1차 캐시에서 조회한다.

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
//1차 캐시에 저장
em.persist(member)
//1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

만약 1차 캐시에 없는 값을 조회하는 경우 DB에서 조회하여 1차 캐시에 저장한 후 값을 반환하게 된다.

...
Member findMember2 = em.find(Member.class, "member2");
...

하지만 고객의 요청이 종료될때 Entity Manager는 삭제되기 때문에 1차 캐시가 성능상 큰 이점을 주지는 않는다.

2. 동일성 보장

같은 영속 Entity를 읽어올 경우 그것에 대한 동일성을 보장한다.

...
Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
//동일성 비료 : true
System.out.printIn(a === b);
...

3. Entity 등록시 Transaction을 지원하는 쓰기 지연(Transactional write-behind)

JPA는 Commit을 하기 전까지는 쓰기 지연 SQL 저장소에 쿼리들을 저장하고, Transaction Commit과 함께 밀린 쿼리들을 DB에 전송하게 된다.

...
//Transaction 시작
transcation.begin();

em.persist(memberA);
em.persist(memberB);
//현재까지 INSERT SQL을 DB에 보내지 않았다.

//Commit하는 순간 DB에 INSERT SQL을 보낸다.
transaction.commit();
...

4. 변경 감지 (Dirty-Check)

JPA는 Persistence Context 안의 1차 캐시에 Entity의 스냅샷을 저장한다. 이 스냅샷은 DB에서 최초로 읽어온 시점의 상태를 저장한 것이다.

...
Member memberA = em.find(Member.class, "member1");
//Entity Data 수정
memberA.setUsername("회원2");
memberA.setAge(10);

transaction.commit();
...

변경 후 Commit 하는 시점에 현재 Entity와 스냅샷을 비교하여 UPDATE SQL을 생성하여 쓰기 지연 SQL 저장소에 저장 후 DB에 전송하게 된다.

Flush

Persistence Context의 변경 내용을 DB에 반영하는 작업이다.

Flush 발생 시

변경 감지
수정된 Entity를 쓰기 지연 SQL 저장소에 등록
쓰기 지연 SQL 저장소의 쿼리를 DB에 전송 (등록, 수정, 삭제 쿼리)
1차 캐시의 내용이 삭제되지는 않는다.

Persistence Context를 Flush 하는 방법

em.flush() : 직접 호출
Transaction Commit : Flush 자동 호출
JPQL 쿼리 실행 : Flush 자동 호출

유의할 것!

Persistence Context를 비우지 않는다.
Persistence Context의 변경 내용을 DB에 동기화한다.
Transaction이라는 작업 단위가 중요하다. 즉 Commit 직전에만 동기화 하면 된다.

준영속 상태

영속에서 준영속으로 바뀐 상태로 영속 상태의 Entity가 Persistence Context에서 분리(detached)되어 Persistence Contest가 제공하는 기능(Dirty Check 등)을 사용하지 못한다.

준영속 상태로 만드는 방법

em.detach(entity) : 특정 Entity만 준영속 상태로 전환
em.clear() : Persistence Context를 완전히 초기화
em.close() : Persistence Context를 종료

[Reference]

Inflearn 김영한 님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 : https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

싱글톤 컨테이너

Sun, 16 May 2021 16:30:58 GMT

싱글톤 패턴

클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴이다.

아래 코드는 싱글톤 패턴의 예시 코드이다.

public class Singleton {
  private static final Singleton instance = new Singleton();
      //private 생성자
      private Singleton(){
      }
      //publice으로 만든 함수로 객체 인스턴스가 필요하면 이 static 메소드를 통해서만 조회 가능
      public static Singleton getInstance(){
          return instanc;
      }
}

static 키워드를 사용하여 메모리 할당을 딱 한번만 하게 한다. 따라서 static 영역에 객체를 딱 1개만 생성한다. 또한 final 키워드를 사용하여 값을 변경하는 것도 막는다. 그리고 private 생성자를 통해 외부에서 임의로 new 키워드를 사용하지 못하도록 막는다.

싱글톤 패턴의 문제점

싱글톤 패턴을 구현하기 위해 코드가 많이 필요하다.
의존관계상 클라이언트가 Singleton Instance를 만드는 구체 클래스에 의존한다. 따라서 DIP(의존성역전)와 OCP(개방 폐쇄)를 위반한다.
테스트하기 어렵다.
내부 속성을 변경하거나 초기화하는 것이 어려워 유연성이 떨어진다.

싱글톤 컨테이너

스프링 컨테이너는 위와 같은 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤 패턴으로 관리한다. 즉 스프링 빈은 싱글톤으로 관리되는 빈이다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 하고, 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
따라서 스프링 컨테이너는 DIP, OCP, 테스트, private 생성자라는 단점으로부터 자유롭게 싱글톤을 사용할 수 있다.

싱글톤 방식의 주의점

싱글톤 방식은 객체 인스턴스를 하나만 생성해서 공유하는 방식이다. 따라서 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계해서는 안된다.
즉 무상태(stateless)로 설계해야한다.
- 특정 클라이언트에 의존적인 필드가 있어선 안된다.
- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
- 따라서 읽기만 가능해야한다.
- 필드 대신 자바에서 공유되지 않는, 지역변수, Parameter, ThreadLocal 등을 사용해야 한다.
  
  @Configuration과 싱글톤
스프링 컨테이너는 싱글톤 레지스트리이다. 하지만 스프링이 자바 코드까지 컨트롤하지는 못한다. 따라서 스프링은 클래스의 바이트를 조작하는 라이브러리를 사용하여 스프링 빈이 싱글톤이 되독록 보장해준다.
만약 @Configuration이 적용된 스프링 빈의 정보를 조회한다면 아래와 같다. bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd982d120
이때 클래스명 이외에 $$EnhancerBySpringCGLIB$$bd982d120와 같은 값이 붙는데 이것은 스프링이 CGLIB라는 바이트 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다.
CGLIB는 @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 그 빈을 반환하고, 스프링 빈이 없으면 생성하여 스프링 빈에 등록하고 반환한다. 따라서 싱글톤이 보장된다.
이때 만약 @Configuration이 적용되지 않고 @Bean만을 사용한다면 스프링 빈에는 등록이 되지만 CGLIB가 작동하지 않아 싱글톤이 보장되지 않는다.

[Reference]

Inflearn 김영한 님의 스프링 핵심 원리 - 기본편 : https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard

스프링 컨테이너

Mon, 10 May 2021 12:32:01 GMT

스프링 컨테이너

AppConfig

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService(){
    ...
    }
    @Bean
    public MemberRepository memberRepository() {
    ...
    }
    @Bean
    public OrderService orderService(){
    ...
    }
    @Bean
    private static DiscountPolicy discouontPolicy() {
    ...
    }
}

OrderApp

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
...
public class OrderApp(){
    ...
        //apc는 ApplicationContext 인터페이스의 구현체이다.
    ApplicationContext apc = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberService memberService = apc.getBean("memberService", MemberService.class);
    OrderService orderService = apc.getBean("orderService", OrderService.class);
    ...
}

ApplicationContext를 스프링 컨테이너라 한다. ApplicationContext은 인터페이스이고 스프링 컨테이너의 최상위 인터페이스인 BeanFactory를 상속받아서 제공한다.
스프링 컨테이너는 XML을 기반으로 만들 수 있고, 매노테이션 기반의 자바 설정 클래스로 만들 수 있다. 위 예시 코드의 AppConfig는 애노테이션 기반의 자바 설정 클래스로 만든 것이다.
스프링 컨테이너는 AnnotationConfigApplicationContext 객체를 통해 @Configuration이 붙은 AppConfig를 설정 정보로 사용한다. 이때 AppConfig 내부의 @Bean이 붙은 메서드를 모두 호출해서 반환된 객 체를 스프링 컨테이너에 등록한다. 그리고 이 객체들을 스프링 빈이라 한다.
스프링 빈은 @Bean이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용하고 이 이름을 인자로 사용하는 applicationContext.getBean("이름", 타입) 메서드로 찾을 수 있다.

스프링 컨테이너 생성 과정

1. 스프링 컨테이너 생성

new AnnotationConfigApplicationContext(AppConfig.class)를 통해 스프링 컨테이너를 생성해준다. 이때 인자 값으로 구성 정보를 입력해주어야 하는데 이 경우 AppConfig.class를 구성 정보로 넘겨주었다.

2. 스프링 빈 등록

스프링 컨테이너는 인자로 넘어온 설정 클래스, 즉 AppConfig의 @Bean이 붙은 메서드들을 스프링 빈 저장소에 이름과 객체 타입으로 등록한다.

3. 스프링 빈 의존관계 설정

스프링 컨테이너는 AppConfig를 확인하고 스프링 빈끼리의 의존 관계를 주입한다. 이것을 DI라고 한다.

BeanFactory와 ApplicationContext

BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다. 하지만 두가지가 같은 것은 아니다.
BeanFactory
스프링 컨테이너의 최상위 인터테이스로 스프링 빈을 관리하고 조회(getBean())하는 역할을 담당한다.

ApplicationContext

BeanFactory의 기능을 상속받은 인터페이스로 스프링 빈을 관리하고 조회하는 역할을 수행한다.
애플리케이션을 개발할 때 빈을 관리, 조회 이외에 MessageSource, EnvironmentCapable, EnvironmentCapable, ApplicationEventPublisher, ResourceLoader의 부가기능을 제공한다.
MessageSource : 메세지 소스를 활용하여 국제화 기능, 예를 들면 한국에서는 한국어로, 영어권에서는 영어로 출력하는 기능이다.
EnvironmentCapable : 환경변수, 개발을 할 때는 크게 3가지 환경이 있는데 로컬용, 개발용, 운영용이 있는데 각 환경 별로 구분해서 처리한다.
ApplicationEventPublisher : 애플리케이션 이벤트를 만들고 구독하든 모델을 편리하게 지원한다.
ResourceLoader : 파일, 클래스 패스, 외부 등에서 리소스를 편리하게 조회한다.

BeanDefinition - 스프링 빈 설정 메타 정보

스프링은 자바 config와 xml 등 다양한 설정 형식을 지원한다. 이것이 가능한 이유에는 BeanDefinition이 있다.
BeanDefinition은 스프링 빈의 정보를 추상화한 것으로 빈 설정 메타 정보라 한다. 즉 스프링 빈을 역할과 구현을 개념적으로 나눈 것이라 볼 수 있다.
자바 코드를 읽든 xml을 읽든 스프링은 BeanDefinition을 만들고 스프링 컨테이너는 코드가 무엇인지는 상관하지 않고 BeanDefinition만 보면 된다.
스프링 컨테이너는 이 BeanDefinition을 기반으로 스프링 빈을 생성하게 된다.

[Reference]

Inflearn 김영한 님의 스프링 핵심 원리 - 기본편 : https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard

IoC, DI, 컨테이너와 컨테이너

Sat, 01 May 2021 15:31:10 GMT

IoC(Inversion of Control : 제어의 역전)

애플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성, 연결하는 별동의 설정 클래스인 AppConfig가 있다고 하자.
위 그림과 같이 OrderServiceImpl은 필요한 인터페이스들을 AppConfig로 부터 호출하지만 어떤 구현 객체들이 실행될지 알 수 없다. 즉 프로그램의 제어 흐름에 대한 모든 권한은 AppConfig가 가지고 있다.
이 처럼 프로그램의 제어 흐름을 OrderServiceImpl이 직접 제어하는 것이 아닌 AppConfig와 같이 외부에서 관리하는 것을 IoC(제어의 역전)이라고 한다.

프레임 워크와 라이브러리

아래 코드는 프레임 워크인 JUnit을 사용한 코드이다. 내가 작성한 코드는 beforeEach()와 join() 뿐이지만 이 코드들을 @Test와 @BeforeEach를 통해 제어하고, 대신 실행한다. 즉 프레임 워크는 내가 작성한 코드를 제어하고, 그것을 대신 실행한다.

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
...
    @BeforeEach
    public void beforeEach(){
        ...
    }
    @Test
    void join(){
        ...
    }
...

라이브러리는 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 라이브라리이다. 예를 들어 내가 코드로 html을 xml로 바꾸는 것을 호출한다면 내 코드가 호출하는 것이므로 그것은 라이브러리이다

DI(Dependecy Injection : 의존관계 주입)

의존관계는 정적인 클래스 의존 관계와 실행 시점(런타임)에 결정되는 동적인 객체 의존 관계로 나뉜다.

정적인 클래스 의존 관계 클래스가 사용하는 import 코드만 보고도 의존 관계를 쉽게 판단할 수 있다. 즉 애플리케이션을 실행하지 않아도 분석 가능하다.

동적인 객체 인스턴스 의존 관계 애플리 케이션 실행 시점에 생성돈 객체 인스턴스의 참조가 연결된 의존관계이다.

의존관계 주입이란 애플리케이션 실행 시점(런타임)에 AppConfig와 같은 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 의존 관계를 연결시키는 것이다.
의존관계 주입을 사용하면 정적인 클래스 의존 관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

컨테이너

Appconfig와 같이 객체를 생성하고 관리하면서 의존 관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다. 주로 DI 컨테이너라 하지만 어셈블러, Object Factory 등으로 불리기도 한다.

[Reference]

Inflearn 김영한 님의 스프링 핵심 원리 - 기본편 : https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard

[Java] final이란?

Sun, 25 Apr 2021 11:25:06 GMT

final 키워드는 entity를 딱 한번만 할당하는 것이다. 따라서 다시 할당하는 경우 error가 발생한다. final은 class, 메소드, 변수에 붙일 수 있고, 각 기능이 다르다.

1. final class

class 앞에 final 키워드를 붙이면 해당 class는 상속되지 않는다.

public final class Fruit{
 ...
}
public class Apple extends Fruit { ... }    // error 발생

2. final 메소드

메서드 앞에 final 키워드를 붙이면 해당 메소드는 더 이상 Overriding 할 수 없다.
메소드 Overriding : 부모 class에서 이미 정의된 메소드를 자식 class에서 같은 이름을 가진 메소드로 재정의하는 것을 말한다.
```
public final class Parent{
 protected final int getGrade() {...}
}
class Child extends Parent { 
  protected int getGrade() {...}    // error 발생
}
```

3. final 변수

변수 앞에 final 키워드를 붙이면 해당 변수는 변경될 수 없다. 따라서 반드시 초기값을 정해줘야한다. 이때 원시변수일 때와 참조변수일 때 차이가 있다.
- 원시 변수에 적용 시 : 해당 변수는 값을 변경할 수 없다.
- 참조 변수에 적용 시 : 참조 변수가 heap 내의 다른 객체를 가리키도록 변경할 수 없다.
```
public final class Parent{
final int childNum = 4;    //반드시 초기값 설정
void getBaby(){
 childNum++;        //error 발생
}
}
```

[Reference]

https://gmlwjd9405.github.io/2018/08/06/java-final.html

HashTable, HashMap, ConCurrentHashMap 차이

Sun, 25 Apr 2021 10:45:31 GMT

HashTable, HashMap, ConCurrentHashMap은 기본적으로 Map 인터페이스를 구현한 클래스이다. Map 인터페이스는 키(key)와 값(value)로 데이터를 관리하며 키를 이용하여 데이터를 추출할 수 있다.

Separate Chaning, Open Addressing

Hash의 기본적인 구조는 key를 hash function을 통해 특정 값으로 변환 후 그 값에 맞는 index를 가진 bucket안에 value를 넣어주는 구조이다. 하지만 넣어주려는 bucket에 이미 값이 있는 경우 충돌을 처리하는 방법에는 2가지 방법이 있다. Separate Chaning와 Open Addressing이다.
Separate Chaning Separate Chaning 방식은 bucket이 list의 포인터를 저장하고 있고, value는 linked list의 헤드에 저장된다. 만약 충돌이 발생했을시 linked list의 헤드의 앞에 추가하는 식으로 구현된다. 하지만 worst case로 한 bucket에만 저장되는 경우 마지막 데이터는 O(N)의 속도를 가지게 되는데 이 문제는 Java 8에서 Red-Black 트리를 사용하여 worst case에도 O(logN)로 탐색이 가능하다

Open Addressing Open Addressing 방식은 bucket에 value를 저장하는 방식이다. 만약 충돌이 발생하면 비어있는 bucket을 찾는 탐색을 하고 빈 bucket에 value를 넣어준다. 탐색 방법에는 Linear Probing, Qudratic Probing, Double Hashing이 있다.

  - Linear Probing : 충돌 발생 지점부터 +1씩 bucket을 탐색한다. 주변의 bucket이 전부 차있는 Primary Clustering 문제가 있다. 캐싱에는 유리하지만 bucket이 가득찰 경우 효율은 급격하게 감소한다.
  - Qudratic Probing : Primary Clustering을 개선하기 위한 방법으로 충돌 발생 지점부터 n²씩 증가시켜 탐색한다. 하지만 초기 hash값이 동일하다면 탐색 과정이 동일하다는 Secondary Clustering 문제가 있다.
  - Double Hashing : 위의 탐색방법들은 규칙성이 생겨 Clustering 문제가 생긴다 따라서 규칙성을 없애기 위해 2차 Hash Function을 이용하여 다음 탐색을 정하게 된다.

1. HashTable

HashTable의 모든 Data 변경 메소드는 syncronized로 선언되어 있다. 따라서 메소드 호출 전 thread간 동기화 lock을 통해 multi thread 환경에서도 data의 무결성을 보장한다. 하지만 이 동기화 락이 매우 느린 동작이어서 단일 thread 환경에서는 HashMap을 사용하는 것이 훨씬 빠르다.

2. HashMap

HashMap은 HashTable과 동일한 내부 구조를 가지고 있지만 HashTable은 syncronized 키워드가 없기 때문에 동기화가 보장되지 못한다. 하지만 동기화 처리를 하지 않기 때문에 value를 찾는 속도는 상당히 빠르다. 또한 HashTable과는 다르게 key와 value가 null값을 허용한다.
HashMap은 충돌 문제를 Separate Chaning을 사용하여 처리한다. 또한 worst case 문제는 java8에서 bucket에 적은 data라면 linked list를 사용하지만 많은 data가 쌓이면 Red-Black tree로 변환한다. 따라서 worst case에도 O(logN)의 속도를 보장한다.

3. ConCurrentHashMap

HashMap과 같은 구조이지만 동기화가 보장되지 않는 HashMap을 보완한 것이 ConcurrentHashMap이다. 하지만 HashMap과는 다르게 key와 value가 null값을 허용하지 않는다.

[Reference]

https://velog.io/@agugu95/Hash-Table-Java-HashMap https://limkydev.tistory.com/40

Java Enum 클래스

Sun, 25 Apr 2021 09:29:24 GMT

1. Enum 클래스

자바에서는 enum을 사용하여 열거체를 사용할 수 있다. 열거체란 말 그대로 변수들을 나열한 것을 말한다.

2. 문법

문법

enum 열거체이름 { value1, value2, value3 , ... }

예시

enum Fruit { Apple, Orange, Peach, ... }

3. 자바 enum의 장점

열거체를 비교할때 실제 값뿐만 아니라 type까지 체크한다.
열거체의 변수값이 바뀌어도 다시 컴파일하지 않아도 된다.

4. 대표 메소드

static E values() : 열거체 모든 변수를 가지는 배열을 생성 후 반환한다.
static E valueOf(String name) : 인자와 일치하는 열거체의 변수를 반환한다.
int ordinal() : 열거체 변수의 index값을 반환한다.

좋은 객체 지향 프로그래밍이란?

Sun, 25 Apr 2021 08:56:34 GMT

객체 지향 특징

추상화
캡슐화
상속
다형성

객체 지향 프로그래밍

객체 지향 프로그래밍이란 프로그램을 여러 개의 독립된 단위인 '객체'들의 모임으로 보는 것이다. 각각의 객체는 메세지를 주고받고, 데이터를 처리하며 협력한다.
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 이때 프로그램을 유연하고 변경이 용이하게 만든다는 것은 컴포넌트를 마치 컴퓨터 부품을 갈아 끼우듯이 쉽고 유연하게 변경하면서 개발하는 것을 말한다.

컴포넌트 : 소프트웨어 시스템에서 독립적인 기능을 하는 모듈이다. 이때 컴포넌트는 객체, 클래스와는 다른 개념이다. 컴포넌트는 꼭 클래스나 객체로 만들어야만 하는 것도 아니고, 하나의 클래스로 구성되어야 하는 것도 아니다. 즉 하나의 컴포넌트는 하나 이상의 클래스들로 구성될 수 있다.

다형성

다형성은 객체 지향의 핵심이다. 다형성을 실세계에 비유하면 세상을 역활과 구현으로 구분하는 것이다. 위 그림을 보면 자동차의 역할을 하는 인터페이스를 사용하여 K3, 아반떼 등 자동차를 구현하면 클라이언트인 운전자는 자동차의 운전방법만 알면 모든 차를 운전할 수 있다. 즉 클라이언트는 구현 대상의 내부 구조를 몰라도 되고, 내부 구조가 변경되거나 구현 대상 자체가 변경되어도 영향을 받지 않는다. 이처럼 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.
자바 언어에 다형성을 적용하면 역할 = 인터페이스, 구현 = 인터페이스를 구현한 클래스, 구현 객체로 분류할 수 있다. 이때 오버라이딩을 통해 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다.
다형성의 본질은 클라이언트를 변경하지 않고, 서버의 구현 기능을 우연하게 변경할 수 있는것이다.

좋은 객체 지향 설계의 5가지 원칙 (SOLID)

1. SRP 단일 책임 원칙

한 클래스는 하나의 책임만을 가진다는 원칙이다. 이때 '하나의 책임'이라는 개념이 모호한데 중요한 기준은 '변경'이다. 특정 클래스를 변경하였을 때 그로인한 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.
책임의 범위를 잘 조절하는 것이 중요한데 책임의 범위가 너무 작을 경우 기능이 너무 쪼깨지게 되고, 범위가 커질 경우 단일 책임 원칙에 위배되기 때문이다. 이처럼 책임의 범위를 적절히 조절하는 것이 객체 지향의 묘미이다.

2. OCP 개방-폐쇄 원칙 (가장 중요한 원칙)

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다는 원칙이다. 확장을 할 때는 다형성을 활용하여 인터페이스를 구현한 새로운 클래스를 만드는 방법 등으로 가능하다.
문제점 : 구현 객체를 변경하기 위해서는 코드를 변경해야한다. 때문에 다형성을 사용하였지만 OCP 원칙을 지킬 수 없게 된다. 이러한 문제를 해결하기 위해 객체를 생성하고, 연관 관게를 맺어주는 조립, 설정자가 필요하고 바로 스프링 컨테이너가 이 역할을 하게 된다.

3. LSP 리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿔야 한다는 원칙이다. 이 때문에 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다. 예를 들면 자동차라는 인터페이스를 구현한 K3에서 엑셀을 밟으면 후진을 하는 기능을 넣는 경우 규약을 어기게 되므로 LSP 원칙이 깨지게 된다.

4. ISP 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 따라서 특정 인터페이스 자체가 변경되어도 클라이언트에 영향을 주지 않게 된다.
이를 통해 인터페이스가 명확해지고, 대체 가능성이 높아진다.

5. DIP 의존관계 역전 원칙 (중요)

구현 클래스에 의존하지 않고, 인터페이스에 의존하라는 원칙이다. 즉 다형성에서 구현보다는 역할에 의존해야 한다는 것이다.
하지만 아래 코드와 같이 MemberService 클라이언트가 구현 클래스를 직접 선택하게 되고, MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존하게 된다. 때문에 DIP를 위반하게 된다.
```
public class MemberService {
  private MemberRepository m = new MemoryMemberRepository();
}
```

정리

객체 지향의 핵심은 다형성
다형성만으로는 OCP, DIP를 지킬 수 없다.

객체 지향 설계와 스프링

객체 지향 프로그래밍에서 다형성 + OCP, DIP를 가능하게 하기 위해 스프링이 개발되었다. 스프링은 DI(Dependency Injection: 의존관계, 의존성 주입) 컨테이너를 제공함으로써 OCP, DIP를 가능하게 지원한다. 이를 통해 클라이언트 코드의 변경 없이 기능을 확장하고, 쉽게 부품을 교체하듯이 개발을 할 수 있게 되었다.

최종 정리

모든 설계에 역할과 구현을 분리하여야 한다.
애플리케이션 설계는 다형성 뿐만 아니라 OCP, DIP를 지켜 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계이다. 이를 위해 스프링 컨테이너를 이용한다.
이상적으로는 모든 설계에 인터페이스를 부여하자. 예를 들면 어떤 DB를 쓸지 정해지지 않은 상황에서 개발해야 하는 경우 인터페이스를 먼저 만들어 놓으면 구현 단계의 선택을 뒤로 미루고 개발할 수 있다. 이처럼 확장과 변경이 용이하다. 하지만 인터페이스를 남발하면 추상화라는 비용이 발생한다. 코드가 추상화되면 구현 코드를 한번에 알아보지 못하고 인터페이스까지 들어가서 확인해야 코드를 이해할 수 있게 된다. 따라서 기능을 확장할 가능성이 없으면, 구체 class를 직접 사용하고, 나중에 필요한 경우 인터페이스를 도입하는 것이 좋다.

[Reference]

Inflearn 김영한 님의 스프링 핵심 원리 - 기본편 : https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard

Spring이란?

Sun, 25 Apr 2021 08:55:25 GMT

1. Spring 생태계

필수 : Spring 프레임워크, Spring 부트
선택 : Spring 데이터, Spring 배치, Spring 세션, Spring 클라우드 등

2. Spring 부트

Spring을 편리하게 사용할 수 있도록 지원
Tomcat 같은 웹 서버를 내장하는 방법으로 단독으로 실행할 수 있는 Spring 어플리케이션을 쉽게 생성

3. 스프링의 핵심

Spring은 자바 언어 기반의 프레임워크
자바 언어의 가장 큰 특징은 객체 지향 언어라는 것이다.
Spring은 객체 지향 언어가 가진 강력한 특징을 살려내어 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크이다.

[Reference]

Inflearn 김영한 님의 스프링 핵심 원리 - 기본편 : https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard

minmin_key.log

값 타입 - 불변 객체, 컬렉션

값 타입과 불변 객체

값 타입 공유 참조

값 타입 복사

객체 타입의 한계

불변 객체

값 타입의 비교

값 타입의 비교

값 타입 컬렉션

값 타입 컬렉션

값 타입 컬렉션의 제약사항

값 타입 컬렉션의 대안

정리

엔티티 타입의 특징

값 타입의 특징

값 타입은 정말 값 타입이라 판단될 때만 사용하자!

엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안된다!

식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 값 타입이 아닌 엔티티를 사용하자!!

[Reference]

값 타입 - 기본값, 임베디드 타입

JPA의 데이터 타입 분류

엔티티 타입

값 타입

값 타입 분류

기본값 타입

참고. 자바의 기본 타입은 절대 공유되지 않는다.

임베디드 타입 (복합 값 타입)

임베디드 타입

임베디드 타입 예시

임베디드 타입의 장점

임베디드 타입과 테이블 매핑

@AttributeOverride : 속성 재정의

[Reference]

프록시와 연관관계 관리

프록시

프록시

프록시 객체

프록시 객체의 초기화

프록시의 특징

프록시 확인

즉시 로딩과 지연 로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

지연 로딩 LAZY를 사용해서 프록시로 조회

즉시 로딩 EAGER를 사용해서 함께 조회

프록시와 즉시 로딩 주의점

지연 로딩 활용 - 실무

영속성 전이 : CASCADE

CASCADE

주의점

CASCADE의 종류

고아 객체

고아 객체

주의점

영속성 전이 + 고아 객체, 생명 주기

[Reference]

@MappedSuperclass

@MappedSuperclass

[Reference]

다양한 연관관계 매핑

연관관계 매핑시 고려사항 3가지

다중성

단방향, 양방향

연관관계의 주인

다대일 [N:1]

다대일 단방향

다대일 양방향

일대다 [1:N]

일대다 단방향

일대다 양방향

일대일 [1:1]

일대일 관계

일대일 : 주 테이블에 외래 키 단방향, 양방향

일대일 : 대상 테이블에 외래 키 단방향, 양방향

다대다 [N:M]

다대다

다대다 매핑의 한계

한계 극복

[Reference]

연관관계 매핑 기초 - 양방향 연관관계