개발 중 JPA 나 MyBatis 에 대해 어떻게 기술 선택 을 하 시 겠 습 니까?

원본 주소:
http://www.spring4all.com/question/112
lexburner 
사흘 전
먼저 개인 적 인 관점 을 표현 하면 JPA 가 선 호 할 수 밖 에 없다.
개인 적 으로 이들 이 사용 하 는 것 이 어떤 차이 가 있 는 지,어떤 것 이 더 편리 한 지,이 두 가지 구 조 를 진정 으로 비교 하기 에는 부족 하 다 고 생각한다.더 우수한 방안 을 평가 하려 면 소프트웨어 디자인 의 측면 에서 평가 할 수 있다 고 생각한다.개인 적 으로 my batis 에 대해 잘 모 르 지만 JPA 규범 과 springdata 의 실현 은 디자인 이념 이 절대적 으로 앞 선다.소프트웨어 개발 의 복잡성 을 해결 하 는 수단 중 하 나 는 DDD(DDD 는 하나의 수단 이지 만 유일한 수단 이 아니다)를 따 르 는 것 이다.나 는 JPA 의 디자인 에서 분야 구동 디자인 사상 을 어떻게 나타 내 는 지,벽돌 을 던 져 옥 을 끌 어 올 리 는 데 중심 을 두 었 다.
집합 루트 와 값 대상
분야 구동 디자인 에는 널리 알려 진 두 가지 개념 이 있 는데 그것 이 바로 entity(실체)와 value object(값 대상)이다.entity 의 특징 은 생명주기 가 있 고 표지 가 있 는 것 이 며 값 대상 은 수식 작용 을 하 는데 변성 이 없고 표지 가 없다.JPA 에 서 는 데이터베이스 의 실체 클래스 에 추가 해 야 합 니 다. @Entity 주 해 는 모두 가 알 아 차 렸 을 것 이 라 고 믿 습 니 다.이것 은 결코 우연 이 아 닙 니 다.

@Entity
@Table(name = "t_order")
public class Order {
    @Id
    private String oid;

    @Embedded
    private CustomerVo customer;
    @OneToMany(cascade = {CascadeType.ALL}, orphanRemoval = true, fetch = FetchType.LAZY, mappedBy = "order")
    private List orderItems;
}

상기 코드 와 같이 Order 는 DDD 의 실체 이 고 CustomerVo,Order Item 은 값 대상 입 니 다.프로그램 설계 자 는 데이터베이스 가 이 필드 를 어떻게 비 추 는 지 에 관심 을 가 질 필요 가 없다.왜냐하면 DDD 에서 해 야 할 일 은 데이터 모델 링 이 아니 라 분야 모델 링 이기 때문이다.실체 와 값 대상 의 의 미 는 여기 서 토론 하지 않 지만 이 를 통 해 실 마 리 를 찾 을 수 있 습 니 다.JPA 의 의 미 는 단순히 ORM 프레임 워 크 가 아 닙 니 다.
창고 에 저장 하 다
Repository 모델 은 영역 구동 디자인 의 또 다른 전형 적 인 모델 이다.초기 에 우 리 는 데이터 액세스 층 을 DAO 라 고 불 렀 는데 SpringData JPA 에서 Repository(창고 저장)라 고 불 렀 다.이것 은 우연 이 아니 라 디자이너 가 의도 적 으로 한 것 이다.
SpringData JPA 를 잘 아 는 친구 들 은 하나의 인터페이스 가 Jpa Repository 인 터 페 이 스 를 계승 한 후에 일련의 자주 사용 하 는 데이터 조작 방법 을 자동 으로 갖 추 었 다 는 것 을 알 고 있다.findAll  findOne  ， save등 이다.

public interface OrderRepository extends JpaRepository{
}

그렇다면 창고 와 다 오 는 어떤 차이 가 있 을 까?이것 은 바로 남 겨 진 문제 와 소프트웨어 디자인 방면 의 요 소 를 언급 해 야 한다.이번 SpringForAll 의 의제 에서 저 는 SpringData JPA 가 확장 가능 한 API 를 가지 고 있다 는 것 을 강조 할 것 이 라 고 예상 할 수 있 습 니 다.아래 와 같이:

public interface OrderRepository extends JpaRepository{

      findByOrderNoAndXxxx(String orderNo,Xxx xx);

    @Transactional
    @Modifying(clearAutomatically = true)
    @Query("update t_order set order_status =?1 where id=?2")
    int updateOrderStatusById(String orderStatus, String id);
}

그러나 내 가 강조 하고 자 하 는 것 은 이것 은 SpringData JPA 의 타협 이 며,이러한 특성 을 지지 하 는 것 은 사용 을 권장 하 는 것 이 아니다.영역 구동 디자인 의 이념 에 맞지 않 기 때문이다.대비 에 주의 하 세 요.SpringData JPA 의 디자인 이념 은 Repository 를 데이터 창고 로 하 는 것 이지 일련의 데이터베이스 스 크 립 트 의 집합 이 아 닙 니 다.findByOrderNoAndXxxx 방법 은 다음 절 에서 언급 할JpaSpecificationExecutor로 대체 할 수 있다.  updateOrderStatusById  방법  findOne  +  save대신 복잡 해 졌 다 고 생각 하지 말고 진정한 업무 장면 을 생각해 보 세 요.수정 작업 은 보통 한 필드 의 수정 만 언급 하지 않 습 니 다.findOne +  save  더욱 복잡 한 업무 수행 을 도 울 수 있 습 니 다.우리 가 SQL 문 구 를 어떻게 작성 해 야 하 는 지 에 관심 을 가지 지 않 아 도 됩 니 다.데이터 베 이 스 를 대상 으로 하 는 SQL 개발 이 아니 라 대상 을 대상 으로 하 는 팬 들 도 더욱 OO 라 고 생각 할 것 입 니 다.
Specification
위 에서 언급 한 SpringData JPA 는 복잡 한 것 을 Specification 모델 로 대체 할 수 있다.  findByOrderNoAndXxxx  SQL 스 크 립 트 조회업무 가 끊임없이 변 하고 있다 는 것 을 생각해 보 세 요.당신 은 미래의 조회 가 하나의 조건 이 더 많아 질 지 어떻게 압 니까?findByOrderNoAndXxxxAndXxxxAndXxxx.... 。SpringData JPA 는 영역 구동 디자인 의 Specification 모델 을 실현 하기 위해 열 에 있 는 Specification 인 터 페 이 스 를 제공 합 니 다.그 중에서 가장 자주 사용 하 는 것 은 Jpa SpecificationExecutor 입 니 다.

public interface OrderRepository extends JpaRepository,JpaSpecificationExecutor{
}

SpringData JPA 를 사용 하여 복잡 한 조회(join 작업,모 으 기 작업 등)를 구축 하 는 것 은 모두 Jpa SpecificationExecutor 가 구축 한 Specification 에 의존 하 는 것 입 니 다.예 는 소개 하지 않 고 좀 길다.
상기 코드 는 하나의 예 가 아 닙 니 다.DDD 디자인 규범 을 진정 으로 따 르 는 시스템 에서 OrderRepository 인터페이스 에서 깨끗 해 야 합 니 다.코드 가 없 으 면 JpaRepository(기초 CRUD 담당)와 Jpa SpecificationExecutor(책임 Specification 조회)만 계승 하면 됩 니 다.물론 SpringData JPA 는 다른 일련의 인 터 페 이 스 를 제공 해 특정 업무 장면 에 따라 계승 하면 된다.
낙관적 자물쇠
데이터 병발 문 제 를 해결 하기 위해 JPA 에서 제공 합 니 다.  @Version  ，보통 Entity 에 하 나 를 추가 합 니 다.  Long version  필드  @Version  주 해 는 스프링 데이터 JPA 도 이 를 고려 했다.이 점 은 JPA 디자인 의 이념 과 SpringData 가 하나의 공정 솔 루 션 으로서 의 쌍 검 을 합 쳐 위대 한 디자인 방안 을 만 들 었 음 을 나타 낸다.
복잡 한 다 중 표 조회
많은 사람들 이 Mybatis 를 선 호 하 는 이 유 는 편리 한 SQL 조작 을 제공 하기 때 문 입 니 다.자유도 가 높 고 포장 성 이 좋 기 때 문 입 니 다...............................................................하지만 SpringData JPA 는 이 를 문제 삼 지 않 는 다.왜?현대 마이크로 서비스의 구조 로 인해 각 서비스 간 의 데이터 베 이 스 는 격 리 된 것 이기 때문에 많은 표를 뛰 어 넘 는 join 작업 본 은 단일 한 업무 데이터 베이스 에 맡 겨 서 는 안 된다.해결 방안 은 elastic Search 를 사용 하여 보기 조회 나 mongodb 와 같은 Nosql 로 완성 하 는 것 입 니 다.문 제 는 원래 문제 가 아니다.
총결산
진정 으로 JPA 에 들 어가 면 SpringData 에 들 어가 면 우 리 는 데이터베이스 조회 문 제 를 해결 하 는 것 이 아니 라 ORM 프레임 워 크 를 사용 하 는 것 이 아니 라 실천 분야 에서 디자인 을 구동 하 는 것 임 을 알 수 있 습 니 다.
(다시 보충:DDD 는 수단 일 뿐 유일한 수단 은 아니다)