JPA - (1)

JPA 소개

모던한 웹 어플리케이션에서 관계형 데이터 베이스는 빠질 수 없는 요소이다. 그러다 보니 객체를 관계형 데이터 베이스에서 관리하는것이 매우 중요해졌다.

관계형 데이터 베이스가 계속해서 웹 서비스의 중심이 되면서 모든 코드는 SQL 중심이 되어간다. 단순 반복적인 SQL을 수백번 해야 된다면 엄청난 스트레스가 될 것이다.

이러한 단순 반복적인 작업 외에도 패러다임의 불일치 문제가 있다. 관계형 데이터 베이스는 어떻게 데이터를 저장 할지에 초점이 맞춰진 기술이다.
반대로 객체 지향 프로그래밍 언어는 메시지를 기반으로 기능과 속성을 한곳에 관리하는 기술이다.

객체지향 프로그래밍에서 부모가 되는 객체를 가져오려면

User user = findUser();
Group group = user.getGroup();

위와 같을 것이다. 하지만 여기 데이터 베이스가 추가 된다면

User user = userDao.findUser();
Group group = groupDao.findGroup(user.getGroupId());

이 처럼 못생긴 코드가 되어버린다. JPA는 이런 문제점을 해결하기 위해 등장하게 됐다. 즉 개발자는 객체지향적으로 프로그래밍을 하고 JPA가 이를 관계형 데이터 베이스에 맞게 SQL을 대신 생성해서 실행한다. 개발자는 항상 객체지향적으로 프로그래밍 할 수 있으므로 더 이상 SQL에 종속적이지 않은 개발을 할 수 있게 된다.

그럼 JPA를 적용한 단순한 domain 클래스를 살펴보자.

@Getter // 6.
@NoArgsConstructor
@Entity // 1.
public class Posts {
    @Id // 2.
    @GeneratedValue(strategy = GenerationType.IDENTITY) // 3.
    private Long id;

    @Column(length = 500, nullable = false) // 4.
    private String title;

    @Column(columnDefinition = "TEXT", nullable = false)
    private String content;

    private String author;

    @Builder // 7.
    public Posts(String title, String content, String author){
        this.title = title;
        this.content = content;
        this.author = author;
    }

}

여기서 Post 클래스는 실제 DB의 테이블과 매칭될 클래스이며, Entity 클래스라고도 한다. JPA를 사용하면 DB데이터에 작업할 경우 실제 쿼리를 날리기보다는, 이 Entity 클래스를 수정함으로써 작업한다.

1. @Entity
   @Entity는 JPA의 어노테이션이다. 테이블과 링크될 클래스임을 나타낸다.

2. @Id
   해당 테이블의 PK 필드를 나타낸다.

3. @GeneratedValue
   PK의 생성 규칙을 나타낸다. Spring Boot 2.0 이상에서는 GenerationType.IDENTITY 옵션을 추가해야만 auto_increment가 된다.

4. @Column
   테이블의 컬럼을 나타내며 굳이 선언하지 않더라도 해당 클래스의 필드는 모두 칼럼이 된다. 하지만 기본값 외에 추가로 변경이 필요한 옵션이 있으면 사용한다.

5. @NoArgsConstructor
   기본 생성자를 자동으로 추가해준다. Public Posts(){}와 같이 효과이다.

6. @Getter
   클래스 내 모든 필드의 Getter 메소드를 자동생성한다.

7. @Builder
   해당 클래스를 빌더 패턴 클래스로 생성한다. 생성자 상단에 선언시 생성자에 포함된 필드만 빌더에 포함한다.

왠만하면 Entity의 PK는 Long 타입의 Auto_increment를 사용하는 것이 좋다. 주민등록번호 같이 유니크 키나 여러 키를 조합한 복합키를 PK로 사용할시 다음과 같은 상황이 발생 할 수 있다.

• FK를 맺을떄 다른 테이블에 복합키를 전부 갖고 있거나, 중간 테이블을 하나더 둬야 하는 상황이 발생
• 인덱스에 좋지 않은 영향이 발생
• 유니크한 조건이 변경될 경우 PK 전체를 수정해야하는 일이 발생

따라서 주민등록번호 같은 유니크 키는 별도로 추가하는것이 좋다.