[Spring] 스프링 DB 2편 - 데이터 접근 활용기술 - 2

https://www.inflearn.com/course/스프링-db-2

스프링 DB 2편 - 데이터 접근 활용 기술 - 인프런 | 강의

 

데이터 접근 기술 - MyBatis

MyBatis 소개 & MyBatis 설정

• JdbcTemplate 보다 더 많은 기능을 제공하는 SQL Mapper 이다.
• JdbcTemplate 은 스프링에 내장된 기능이고, 별도의 설정업싱 사용할 수 있으나 MyBatis 는 약간의 설정이 필요하다.
• ORM 기술 사용하다가 동적쿼리나 native 쿼리 필요시, QueryDsl 을 사용하나 jdbcTemplate 까지 써서 해결하는 경우가 많음 (MyBatis 까지는 사용하지 않음)
• Mybatis 는 버전 정보를 설정해줘야함 (Spring 에서 공식적으로 지원하는건 아님)
• mybatis.type-aliases-package : 패키지명 안적게함 (; , 로 여러개 입력 가능)
  mybatis.configuration.map-underscore-to-camel-case : 데이터베이스가 언더바여도 객체의 낙타표기법에 맞춰줌 (관례의 불일치)
• ibatis 는 mybatis 예전 버전 으로 이해하면 된다.

MyBatis 적용 1 - 기본, 설정과 실행, 분석

• getter 를 사용하여 파라미터를 주입한다.
• < == $lt
• mybatis.mapper-locations 옵션을 설정해두면 해당 하위폴더에 있는 XML 을 XML 매핑 파일로 인식한다.
  => 테스트의 properties 파일도 수정해야함
• <where> 는 <if> 와 사용하며 and 를 적절하게 바꿔준다.
• CDATA 로 특수문자 (< , >) 를 사용할수 있음
• 설정원리

• 매퍼 구현체는 예외 변환까지 처리해준다. MyBatis 에서 발생한 예외를 스프링 예외 추상화인 DataAccessException 으로 변환하여 반환해준다.

MyBatis 기능 정리2 - 동적 쿼리 , 기타 기능, 정리

• 동적 SQL
  - if 
    - 내부 문법은 OGNL을 사용한다.
    - <where> 태그를 사용해야 모든 if 문이 만족하지 않을때를 해결할 수 있다. (그렇지 않으면 where 만 남게된다.)
    - <trim prefix="WHERE" prefixOverrides="AND |OR"> 를 사용할 수도 있음
  -choose (when, otherwise)
  - trim (where, set), foreach
• 기타 기능
  - XML 대신 애노테이션에 SQL을 작성할 수 있다.
    - 동적쿼리가 해결되지는 않는다.
    - ex. @SELECT("select id from item where id=#{id}")
  - 문자열 대체
    - #{} 문법은 ? 를 넣고 파라미터 바인딩 하는 PreparedStatement 를 사용한다.
    - 때로는 파라미터 바인딩이 아니라 문자 그래도를 처리하고 싶은 경우, ${} 를 사용하면 된다.
      - ${} 를 사용하면 SQL 인젝션 공격을 당할 수 있다. 주의 깊게 사용해야함 (주로 칼럼명을 담을때 사용할수도 있다.)
  - 재사용 가능한 SQL 조각
    - <include> 를 통해서 <sql> 조각을 찾아서 사용할 수 있다.
  - Result Maps
    - 별칭을 통해 칼럼명과 객체의 프로퍼티 명을 일치할 수 있음
    - 별칭을 사용하지 않고도 문제를 해결할 수 있는데, <resultMap> 태그를 사용한다.
  - 복잡한 결과매핑
    - <association>, <collection> 을 사용하여 관계매핑이 가능하다.
    - 다만 성능최적화를 기대하기 어려워서 신중하게 사용
    - 공식 문서 참고 필요 : https://mybatis.org/mybatis-3/ko/sqlmap-xml.html#Result_Maps
  
  

MyBatis – 마이바티스 3 | 매퍼 XML 파일

 

데이터 접근 기술 - JPA

JPA 시작, ORM 개념1 - SQL 중심적인 개발의 문제점

• SQL 에 의존적인 개발을 피하기 어렵다.
• 패러다임의 불일치
  - 객체 vs 관계형 데이터베이스
• 객체 <=> RDB 데이터 전환 해주는 사람
  = 개발자 == SQL 매퍼
• SQL 사용시 DB에 저장할 객체는 상속관계를 잘 쓰지 않음 (사용자가 분리를 해줘야함)
  => 객체를 테이블에 맞추어 모델링함
  => 객체 다운 모델링은 외래키를 가지고 있는게 아니라 모델을 가지고 있어야함
• 모든 객체를 미리 로딩할 수는 없다.
  => 상황에 따라 동일한 회원 조회 메서드를 여러벌 생성
• 엔티티 신뢰 문제
  => 진정한 의미의 계층 분할이 어렵다.
• 객체답게 모델링 할수록 매핑 작업만 늘어난다.
• 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?
  => JPA

ORM 개념2 - JPA 소개

• JPA : Java Persistent API
• ORM : Object-relational mapping (객체 관계 매핑)
• JPA 는 인터페이스의 모음
  - JPA 2.1 표준 명세를 구현한 3가지 구현체
• JPA를 왜 사용해야 하는가?
  - SQL 중심적인 개발에서 객체 중심으로 개발
  - 생산성, 유지보수, 패러다임의 불일치 해결 등
• JPA의 성능 최적화 기능
  - 1차 캐시와 동일성 보장
    - 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
    - DB Isolation Level이 Read Commit 이어도 애플리케이션에서 Repeatable Read 보장
  - 트랜잭션을 지원하는 쓰기 지연
    - 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
    - JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
  - 지연 로딩과 즉시 로딩
    - 지연 로딩 : 객체가 실제 사용될 때 로딩
    - 즉시 로딩 : JOIN SQL 로 한번에 연관된 객체까지 미리 조회
• ORM 은 객체와 RDB 두 기둥위에 있는 기술

JPA 적용1 ,2 - 개발, 리포지토리 분석

• @GenratedValue(Strategy = GenerationType.IDENTITY) 
  => IDENTITY 전략은 DB에서 값을 채워줌
• 객체 필드의 카멜케이스를 테이블 컬럼의 언더스코어로 자동 변환해줌
• 복잡한 조건 조회시 JPQL 사용한다.
  테이블이 아닌 엔티티 객체를 대상으로 SQL 을 실행한다.
  파라 미터 작성시 :parameter
  바인딩시 , setParameter("parameter", param) 메소드 활용
  - 다만 동적쿼리 문제가 존재하여 QueryDsl 을 활용한다.

JPA 적용 3 - 예외 변환

• EntityManager 는 순수한 JPA 기술이고, 스프링과는 관계가 없으므로, JPA 관련 예외를 발생시킨다.
• JPA 는 `PersistenceException` 과 그 하위 예외를 발생시킨다.
• @Repository 가 붙은 클래스는 컴포넌트 스캔의 대상이 된다.
  @Repository 가 붙은 클래스는 예외 변환 AOP 의 적용 대상이 된다.
    - 스프링과 JPA 를 함께 사용하는 경우, 스프링은 JPA 예외 변환기(`PersitenceExceptionTranslator`)를 등록한다.
  => 결과적으로 @Repository 어노테이션이 있으면 스프링이 예외 변환을 처리하는 AOP 를 만들어준다.