💡 Mac 환경 기준으로 작성된 글입니다.

1. IntelliJ IDEA > Preferences 선택

2. Version Control > GitHub 선택 후 상단 메뉴의 'Log In to GitHub Enterprise' 클릭

3. Generate 클릭

4. Github 토큰 발급 화면의 토큰 복사 후 'Add Account' 클릭

5. 정상 연결 시 아래와 같이 목록에 표시됨

읽어주셔서 감사합니다 :)

이러한 정보가 포함된 소스를 Github와 같이 공개된 장소에 올리게 된다면 보안적으로 문제가 발생할 수 있습니다.

이번 글에서는 이러한 개발 정보를 암호화해주는 Jasypt 라이브러리에 대해 정리해보겠습니다~

💡Jasypt란?

개발자가 간단히 프로젝트에 기본 암호화 기능을 사용할 수 있도록 지원해주는 Java 라이브러리입니다.

Jasypt 적용

실제로 Jasypt를 이용해 설정 파일 내 민감 정보를 암호화해보겠습니다.

의존성 추가

먼저 암호화 기능을 사용하기 위해 dependencies에 해당 라이브러리를 추가해줍니다.

dependencies {
    implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.4'
}

Encrypt Key 생성

Jasypt 암복호화 사이트 jasypt 관련 설정 시 password를 설정하는 부분이 있는데 이 설정이 노출되는 경우 프로젝트 내에 암호화된 값을 복호화할 수 있기에, 위 사이트를 통해 jasypt password를 암호화합니다.

Config 생성

@Configuration
@EnableEncryptableProperties
public class JasyptConfig {
    @Bean(name = "encryptorBean")
    public StringEncryptor stringEncryptor(SimpleStringPBEConfig simpleStringPBEConfig) {
        PooledPBEStringEncryptor stringEncryptor = new PooledPBEStringEncryptor();
        stringEncryptor.setConfig(simpleStringPBEConfig);
        return stringEncryptor;
    }

    @Bean
    @ConfigurationProperties("config.encrypt")
    public SimpleStringPBEConfig simpleStringPBEConfig() {
        return new SimpleStringPBEConfig();
    }
}

설정 추가

jasypt.ecryptor.bean에 위 Config에서 명시한 Bean 입력 config.ecrypt.password는 위에서 사이트를 통해 암호화 한 password 입력

jasypt:
  encryptor:
    bean: encryptorBean
config:
  encrypt:
    password: ie2Fa4lO1v1ODSx738OIUEiv/9rAFOqk
    algorithm: PBEWithMD5AndDES
    provider-name: SunJCE
    pool-size: 1
    key-obtention-iterations: 1000
    string-output-type: base64

테스트 함수를 이용해 암호화 password 구하기

@SpringBootTest
class JasyptConfigTest {
    @Autowired
    @Qualifier("encryptorBean")
    private StringEncryptor stringEncryptor;

    @Test
    public void generatePassword() {
        String encrypt = stringEncryptor.encrypt("password");
        System.out.println(encrypt);
        String decrypt = stringEncryptor.decrypt(encrypt);
        System.out.println(decrypt);
    }
}

암호화 password 적용

ENC("암호화 password") 형식으로 암호화된 값 적용

spring:
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost:3306
    username: dbuser
    password: ENC(WHXxOvGjJa7qXjALhA7ghdoYksJjabL/)

🔗 참고 URL

• http://www.jasypt.org/
• https://github.com/ulisesbocchio/jasypt-spring-boot

이 글은 김영한님의 '자바 ORM 표준 프로그래밍' 교재를 바탕으로 정리한 글입니다. :)

이번엔 JPA의 핵심 개념인 엔티티와 테이블 매핑에 대해 정리해보겠습니다~🤸

매핑 어노테이션

@Entity

JPA를 사용해서 테이블과 매핑할 클래스에 사용한다.

속성

• name: JPA에서 사용할 엔티티 이름 지정한다. 설정하지 않으면 클래스 이름을 그대로 사용.

주의사항

• 기본 생성자는 필수
• final 클래스, inner 클래스, enum, interface에서 사용 불가
• 저장 필드에 final 사용 불가

@Table

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

속성

• name: 매핑할 테이블 이름(dafault: 엔티티 이름)
• catalog: 해당 기능이 있는 데이터베이스에서 매핑
• schema: 해당 기능이 있는 데이터베이스에서 매핑

스키마 자동 생성 설정

JPA는 클래스의 매핑 정보를 통해 각 데이터베이스에 맞게 스키마를 자동 생성하는 기능을 지원한다.

아래와 같은 설정을 통해 애플리케이션 실행 시점에 데이터베이스 테이블을 자동으로 생성할 수 있다.

spring:
  jpa:
    hibernate:
      ddl-auto: create

위와 같이 설정 후 실행 시 콘솔에 출력되는 스키마 생성 로그. 기존 테이블을 삭제하고 재생성한다.

drop table if exists member;

create table member (
    member_id bigint not null,
    city varchar(255),
    street varchar(255),
    zipcode varchar(255),
    username varchar(255),
    primary key (member_id)
)

hibernate.ddl-auto 속성

• create : 기존 테이블을 삭제하고 새로 생성한다. DROP + CREATE
• create-drop : create 속성에 추가로 애플리케이션 종료 시 생성한 DDL을 제거한다. DROP + CREATE + DROP
• update : 테이블과 엔티티를 비교해 변경 사항을 수정한다.
• validate : 테이블과 엔티티를 비교해 차이가 있으면 경고를 남기고 애플리케이션을 실행하지 않는다.
• none : 자동 생성 기능 사용 X

  운영 환경에서 create, create-drop, update와 같이 DDL을 수정하는 옵션은 실사용되는 테이블이나 컬럼을 삭제할 수 있기 때문에 사용하면 안된다.

위 설정은 환경별로 알맞은 값을 사용해야 한다. 일반적으로 추천하는 상황별 전략은 아래와 같다.

• 개발 초기: create, update
• 초기화 상태로 테스트를 진행하는 개발자 환경과 CI 서버: create, create-drop
• 테스트 서버: update, validate
• 스테이징, 운영: validate, none

제약조건 추가

엔티티 관련 제약조건이 추가되는 경우 @Column의 속성을 이용해 이를 설정할 수 있다.

@Entity
public class Member {

    @Id
    @Column(name="member_id")
    private Long id;

    @Column(nullable = false, length = 20)
    private String username;
    ...
}

위와 같이 자동 생성되는 DDL의 username 컬럼에 not null 제약조건과 length를 지정할 수 있으며 생성된 DDL은 아래와 같다.

create table member (
       member_id bigint not null,
        city varchar(255),
        street varchar(255),
        zipcode varchar(255),
        username varchar(20) not null,
        primary key (member_id)
    )

@Table의 uniqueConstraints 속성을 통해 유니크 제약조건 부여도 가능한다.

@Entity
@Table(uniqueConstraints = {
        @UniqueConstraint(
                name = "ID_NAME_UNIQUE",
                columnNames = {"MEMBER_ID", "USERNAME"}
        )
})
public class Member {

    @Id
    @Column(name="member_id")
    private Long id;

    @Column(nullable = false, length = 20)
    private String username;
    ...
}

생성된 DDL은 아래와 같다.

alter table member 
       add constraint ID_NAME_UNIQUE unique (member_id, username)

기본키 매핑 전략

데이터베이스마다 기본 키를 생성하는 방식이 서로 달라 JPA는 이를 위해 기본 키 매핑 기능을 제공한다.

• 직접 할당: 기본 키를 애플리케이션에서 직접 할당, 식별자 값 없을 경우 예외 발생.

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

• IDENTITY: 기본 키 생성을 데이터베이스에 위임. 엔티티를 저장한 직후 할당된 식별자 값을 엔티티에서 조회해 저장.

    @Entity
    public class Member {
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private Long id;

• SEQUENCE: 데이터베이스 시퀀스를 통해 기본 키 할당. 엔티티 저장 시 시퀀스를 사용해 식별자를 먼저 조회한 후 이를 데이터베이스에 저장한다.

    @Entity
    public class Member {
        @Id
        @GeneratedValue(strategy = GenerationType.SEQUENCE,
                                  generator = "MEMBER_SEQ_GENERATOR")
        private Long id;

• TABLE: 키 생성용 테이블을 만들어 시퀀스처럼 사용. 내부 동작방식은 SEQUENCE 전략과 동일.

    @Entity
    public class Member {
        @Id
        @GeneratedValue(strategy = GenerationType.TABLE,
                                  generator = "MEMBER_SEQ_GENERATOR")
        private Long id;

• AUTO: 데이터베이스에 따라 알맞은 전략 선택(Default / Oracle: SEQUENCE, MySQL: IDENTITY)

필드와 컬럼 매핑

@Enumerated

자바의 enum 타입을 매핑할 때 사용한다.

회원 별로 주소 정보를 가지고 있다고 가정할 때 주소 정보를 아래와 같이 JPA enum 어노테이션을 통해 표현할 수 있다.

@Entity
public class Member {
    @Id
    @GeneratedValue
    @Column(name="member_id")
    private Long id;

    private String username;

    @Embedded
    private Address address;
}

@Embeddable
public class Address {
    private String city;
    private String street;
    private String zipcode;
}

읽어주셔서 감사합니다~ :)

이 글은 김영한님의 '자바 ORM 표준 프로그래밍' 교재를 바탕으로 정리한 글입니다. :)

이번 글에서는 JPA의 강점 중 하나인 영속성 관리에 대해 설명해보겠습니다~!🕺💃

엔티티 매니저

엔티티 매니저: 엔티티 저장, 수정, 조회 등 엔티티와 관련된 모든 일을 처리하며 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 얻지 않는다(ex: 트랜잭션 시작 시). 여러 스레드가 동시에 접근하면 동시성 문제가 발생하기에 스레드 간에 공유해선 안된다.

엔티티 매니저 팩토리: 이름 그대로 엔티티 매니저를 만드는 공장으로, 이 공장을 만드는 비용이 상당히 크다. 때문에 애플리케이션 전체에서 엔티티 매니저 팩토리 하나를 공유해서 사용한다. 스프링 부트에서는 이를 자동으로 설정해준다.

엔티티의 생명주기

• 비영속(new/transient): 영속성 컨텍스트에 속하지 않은 상태
• 영속(managed): 영속성 컨텍스트에 저장된 상태
• 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제(removed): 삭제된 상태

영속성 컨텍스트

💡 영속성 컨텍스트란? JPA를 이해하는 데 있어 가장 중요한 개념이다. '엔티티를 영구 저장하는 환경'이라는 뜻으로 엔티티 매니저로 엔티티를 저장하거나 조회할 때 영속성 컨텍스트에 엔티티가 1차적으로 보관 및 관리된다.

특징

• 식별자 값으로 구분 영속성 컨텍스트는 엔티티를 식별자 값(@Id, 테이블의 기본 키에 매핑)으로 구분하기에 식별자 값이 반드시 있어야 한다.
• 트랜잭션 커밋 시 데이터베이스에 저장 JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 저장된 엔티티를 데이터베이스를 반영한다. 이것을 플러시(flush)라 한다.

장점

• 1차 캐시 영속성 컨텍스트는 내부에 캐시를 가지고 있는데 이것을 1차 캐시라 한다. 캐시에 저장된 엔티티는 @Id로 매핑된 식별자로 구분된다. 엔티티 조회 시 가장 먼저 메모리에 있는 1차 캐시를 검색한다. 만약 찾는 엔티티가 캐시에 없으면 엔티티 매니저는 데이터베이스를 조회해 엔티티를 생성한 후 1차 캐시에 저장한 뒤 해당 엔티티를 반환한다. 아래 예시 코드로 관련 내용을 확인할 수 있다.

  

  

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

   //1차 캐시에 저장
   em.persit(member);

   //1차 캐시에서 조회
   Member findMember1 = em.find(Member.class, "member1");

   //DB에서 조회
   Member findMember2 = em.find(Member.class, "member2");

• 동일성 보장 아래와 같이 동일 식별자로 같은 엔티티를 여러번 조회하는 경우, 영속성 컨텍스트가 1차 캐시에 있는 같은 인스턴스를 계속 반환해 성능상 이점과 엔티티의 동일성을 보장한다.

   Member a = em.find(Member.class, "member1");
   Member b = em.find(Member.class, "member1");
  
   System.out.println(a == b); //true

• 트랙잭션을 지원하는 쓰기 지연 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 엔티티를 저장하지 않고 내부 쿼리 저장소에 SQL을 모아둔다. 그래고 트랜잭션 커밋 시 모아둔 쿼리를 동시에 보낸다. 이 기능을 통해 모아둔 등록 쿼리를 데이터베이스에 한 번에 전달하면 성능을 최적화할 수 있다.

• 변경 감지 JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초 상태인 스냅샷을 복사해서 저장한다. 그리고 플러시 시점에 스냅샷과 엔티티를 비교해 변경이 감지되었을때 수정 쿼리를 생성해 내부 쿼리 저장소에 저장한다. 또한 JPA 기본 전략으로 인해 변경 감지 시 모든 필드가 업데이트 된다. 이 전략은 수정 쿼리가 항상 같고 데이터베이스에서 한 번 파싱된 쿼리를 재사용할 수 있다는 장점이 있다.

  필드가 많거나 저장되는 내용이 너무 큰 경우에는 하이버네이트 확장 기능(@DynamicUpdate)를 사용하면 되지만, 이를 사용하면 캐시된 쿼리를 사용하지 않고 새로운 쿼리를 생성해 오버헤드가 발생한다고 합니다... 약 30개 정도되는 컬럼을 수정하는 경우는 되어야 기본 전략보다 빠르다고 하네요...

플러시

플러시(flush)는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다. 실행 시 변경 감지가 동작해 수정 엔티티에 대한 쿼리를 생성하고 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.

호출 방법

플러시 호출 방법은 아래 세 가지가 있다.

• 직접 호출: flush() 함수를 직접 호출해 영속성 컨텍스트를 강제로 플러시한다. 테스트나 특수한 경우를 제외하고 거의 사용하지 않는다.
• 트랜잭션 커밋 시 자동 호출: JPA는 트랜잭션 커밋 시 플러시를 자동으로 호출해준다.
• JPQL 실행 시 자동 호출: JPQL과 같은 객체지향 쿼리를 호출할 때도 JPA가 자동으로 플러시를 호출해준다.

옵션

1. FlushModeType.AUTO(Default): 커밋이나 쿼리 실행 시 플러시
2. FlushModeType.COMMIT: 커밋할 때만 플러시

   em.setFlushMode(FlushModeType.COMMIT);

준영속

준영속이란 영속성 컨텍스트가 관리하는 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 상태로, 준영속 상태의 엔티티는 영속성 컨텍스트가 제공하는 기능을 사용할 수 없다.

준영속 상태로 전환되는 경우는 아래 세가지이다.

• 준영속 상태로 전환: em.detach(entity) 영속성 컨텍스트에 더 이상 해당 엔티티를 관리하지 말라고 알려준다. 호출 시 1차 캐시와 쓰기 지연 SQL 저장소에서 해당 엔티티 관련된 모든 정보가 제거된다.
• 영속성 컨텍스트 초기화: em.clear() 영속성 컨텍스트를 초기화해 모든 엔티티를 준영속 상태로 만든다.
• 영속성 컨텍스트 종료: em.close() 영속성 컨텍스트 자체를 종료시킨다.

병합

준영속이나 비영속 상태의 엔티티를 영속 상태로 변경하기 위해 병합 함수인 merge()를 사용한다. 병합 함수는 파라미터로 엔티티를 받아 식별자로 영속성 컨텍스트와 데이터베이스를 조회한 후 찾는 엔티티가 없으면 받아온 엔티티 정보로 새로운 영속 상태의 엔티티를 생성해 반환한다.

public static void main(String args[]){
    Member member = createMember("memberA", "userA");

    member = mergeMember(member);
}

public Member createMember(String id, String name){
    EntityManager em;

    //회원 생성
    Memeber member = new Member();
    member.setId(id);
    member.setName(name);

    em.persist(member);

    //영속성 컨텍스트 종료
    em.close();
}

public Member mergeMember(Member member){
    EntityManager em;

    //병합 엔티티 반환
    return em.merge(member);
}

읽어주셔서 감사합니다. 🐥

이 글은 김영한님의 '자바 ORM 표준 프로그래밍' 교재와 '실전! 스프링 부트와 JPA 활용' 강의를 바탕으로 정리한 글입니다. :)

이번 글에서는 실제로 동작하는 JPA 소스에 대해 간단히 살펴보겠습니다. 😚

JPA 테스트 시 사용될 기본적인 프로젝트 세팅은 https://start.spring.io/ 페이지에서 진행할 수 있습니다.

객체 매핑

JPA를 사용하려면 가장 먼저 클래스와 테이블을 매핑해야 한다.

테이블

예시로 아래와 같은 회원 테이블과 있다고 가정해보자.

create table member
(
    member_id bigint       not null    primary key,
    name  varchar(255) null,
    city      varchar(255) null,
    street    varchar(255) null,
    zipcode   varchar(255) null
);

클래스

회원 클래스에 JPA가 제공하는 매핑 어노테이션이 추가해 테이블을 표현할 수 있다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    @Column(name="member_id")
    private Long id;

    private String name;

    @Embedded
    private Address address;

    @OneToMany(mappedBy = "member")
    private List<Order> orderList = new ArrayList<>();
}

• @Entity 엔티티 클래스를 테이블과 매핑한다고 JPA에 알려준다.
• @Table 엔티티 클래스에 매핑할 테이블 정보를 알려준다. 여기서는 엔티티와 테이블 명이 동일하기에 생략되었다.
• @Id 필드를 테이블의 기본 키(Primary key)에 매핑한다.
• @GeneratedValue 기본키 매핑 전략 AUTO: 데이터베이스에 따라 알맞은 전략 선택(Default / Oracle: SEQUENCE, MySQL: IDENTITY) IDENTITY: 기본 키 생성을 데이터베이스에 위임 SEQUENCE: 데이터베이스 시퀀스를 통해 기본 키 할당 TABLE: 키 생성용 테이블을 만들어 시퀀스처럼 사용
• @Column 필드를 컬럼에 매핑한다. 해당 어노테이션이 없는 경우 동일한 이름의 컬럼(대소문자 구분은 데이터베이스에 따라 다르므로 유의!)을 찾아 자동 매핑한다.
• @Embedded 사용자가 정의한 값 타입을 지정할 수 있다.(연관도 있는 값들로 분류해 응집력 ↑)
• @OneToMany 양방향 연관관계 매핑, 해당 어노테이션은 일대다 관계를 나타낸다.

  매핑 관계

  객체 매핑이 된 테이블과 클래스의 관계는 아래와 같이 나타난다.

비즈니스 로직

실제로 JPA를 이용하는 간단한 코드를 알아보도록 하자.

EntityManager em;

String memberId = "user1";

Member member = new Member();
member.setId(memberId);
member.setName("James");
member.setId(20);

// 등록
em.persist(member);

// 조회
Member findMember = em.find(Member.class, memberId);

// 수정
member.setAge(21);

// 삭제
em.remove(member);

수정의 경우 별도의 엔티티 매니저 함수를 이용하지 않고 단순히 엔티티의 값만 변경했다. JPA는 어떤 엔티티가 변경되었는지 추적하는 기능을 갖추고 있기에 엔티티의 값만 변경하면 자동으로 UPDATE문을 생성해 데이터베이스의 값을 변경한다. 엔티티 매니저는 엔티티의 등록, 조회, 삭제와 같은 기본적인 함수를 제공하기에 개발자는 SQL을 작성할 필요없이 이 함수를 이용하면 된다. 실제 SQL은 JPA가 자동으로 생성해 데이터베이스에 넘겨준다.

JPQL

위에서 예시로 든 예제는 엔티티 매니저의 함수를 통해 처리 가능한 단순한 코드였다. 하지만 실제 실무에서는 위 함수로 처리할 수 없는 복잡한 로직을 만들어야할 경우가 생긴다. 이에 JPA는 엔티티 객체를 대상으로 쿼리하는 JPQL을 제공한다.

EntityManager em;

List<Member> memberList = em.createQuery("select m from Member m", Member.class)
                .getResultList();

JPQL은 위와 같이 엔티티 매니저의 createQuery 함수를 통해 쿼리 객체를 생성하며 이를 getResultList()로 리턴한다.

읽어주셔서 감사합니다. 🙇‍

이 글은 김영한님의 '자바 ORM 표준 프로그래밍' 교재를 바탕으로 정리한 글입니다. :)

💡JPA란?

객체와 관계형 DB 간의 차이를 해결해 주는 ORM 프레임워크이다. JPA는 개발자 대신 적절한 SQL(CRUD)를 생성해 데이터베이스에 전달해 줄 뿐만 아니라 기존 JDBC API의 패러다임 불일치 문제도 해결해 준다.

ORM(Object-Relational Mapping)은 이름 그대로 객체와 관계형 데이터베이스를 매핑해준다. JPA는 이러한 ORM 기술에 대한 API 표준 명세이다. 현재 다양한 ORM 프레임워크이 존재하지만 그중 하이버네이트가 가장 대중적으로 사용된다.

JPA의 필요성

SQL을 직접 다룰 때 발생하는 문제

• 객체와 데이터베이스 간 구조적 차이 보통 데이터베이스는 객체 구조와는 다른 데이터 중심의 구조를 가진다. 때문에 객체를 직접 DB에 저장하지 못하고 개발자가 객체와 DB 사이에서 SQL과 JDBC API를 이용해 변환 작업을 직접 해줘야 한다. 이러한 이유로 애플리케이션이 점점 커질수록 작업해야 할 SQL과 API는 무수히 늘어날 것이다.

• SQL에 의존적인 개발 객체 간의 연관관계를 전적으로 SQL을 통해 표현하기 때문에 논리적으로 엔티티와 SQL 사이에 강력한 의존관계가 발생한다. 이로 인해 엔티티 수정이 필요할 경우 DAO를 열어 실행되는 SQL을 확인해야 하고 이는 진정한 의미의 계층 분할이 아니다.

• 유지보수의 어려움 위와 같이 엔티티와 SQL 간 강력한 의존관계가 생긴다. 때문에 엔티티에 변경이 일어날 때 관련 DAO와 SQL 대부분을 변경해야 해 유지보수가 어려워지는 문제가 발생한다.

JPA의 장점

• 생산성 기존에는 개발자가 SQL을 작성하고 JDBC API를 사용하는 반복적인 작업을 모두 진행해야 했지만 JPA는 이러한 작업을 모두 대신 처리해 준다.

• 유지보수 SQL을 직접 다루는 경우, 엔티티에 변경이 일어나면 관련 SQL을 모두 수정하는 작업이 필요하다. 하지만 JPA를 사용하면 이러한 작업을 JPA가 대신해주기에 개발자가 유지보수해야할 코드 수가 적어진다.

• 패러다임의 불일치 해결 상속, 연관관계, 객체 그래프 탐색, 비교하기와 같이 객체와 관계형 데이터베이스 사이에서 발생하는 패러다임 불일치 문제를 JPA를 사용해 해결할 수 있다.

• 성능 JPA는 엔티티 매니저 내부에 영속성 컨텍스트를 두어 엔티티를 비휘발성으로 관리한다. 예를 들어 아래와 같이 같은 트랜잭션 안에서 동일 데이터를 조회하는 코드가 있다고 가정해 보자.

  EntityManager em;
  
  String memberId = "user1";
  Member member1 = em.find(memberID);
  Member member2 = em.find(memberID);

  엔티티 매니저를 통해 데이터가 한 번 조회해왔다면 이 이후부터 조회되는 데이터는 엔티티 매니저에 이미 저장된 데이터를 조회하기 때문에 DB 통신을 여러 번 하지 않는다. 이러한 동작 방식을 통해 JPA는 애플리케이션과 데이터베이스 사이에서 최적화된 성능을 지원한다.

• 데이터 접근 추상화와 벤더 독립성 아래와 같이 JPA는 애플리케이션과 데이터베이스 사이 추상화된 접근 계층을 제공하기에 특정 데이터베이스 기술에 종속되지 않는다. 때문에 데이터베이스를 변경하게 되더라도 일부 설정만 변경해 주면 된다.

• 표준 JPA는 자바 진영의 ORM 기술 표준이다.

읽어주셔서 감사합니다. 🥳