나는 지금까지 mybatis만 사용해왔는데 오늘은 JPA를 학습해보고자 한다.

예전에는 대부분의 기업에서 mybatis를 사용했지만 요즘 서비스 기업에서의 JPA사용률은 점점 올라오고 있다. 평균치를 봤을 때는 아직까지 mybatis가 많이 사용되지만 그에 못지않게 JPA의 사용량도 늘고 있다.
두 가지 모두 핫하니까 둘 다 공부해보자!!가 결론이다..ㅎ
각설하고, 현재 대부분은 RDB를 이용하는 추세이다. (NoSQL,하둡도 나오고 있지만..)
지금 시대는 객체를 RDB에 관리하게 된다. 그럼 자동반사적으로 따라오는것이 SQL이며, SQL중심의 개발은 문제점이 존재한다.
SQL 중심 개발의 문제점
- 무한 반복, 지루한 코드
- CRUD의 반복
- 자바 객체를 SQL로,, SQL을 자바 객체로,,
- query를 직접 짜야한다
- 비슷하면서도 다른 쿼리들의 반복
- 패러다임의 불일치
- 객체 vs 관계형 DB
- 객체지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템 복잡성을 제어할 수 있는 다양한 장치를 제공하지만 관계형 DB는 아님

- 업무의 대부분은 SQL을 작성하며 시간을 보내게 된다 (mapper 짜기..)
객체와 RDB의 차이
- 상속

- 연관관계
- 객체는 참조를 사용 : member.getTeam()
- 테이블은 외래 키를 사용 : JOIN ON M.TEAM_ID = T.TEAM_ID


- db가 개입되면 코드가 복잡해짐

- 컬렉션만 사용할 땐 매우 간단
- 엔티티 신뢰 문제

- 값이 있을지 없을지 모름 (모든 로직을 체크해야만, 다 까봐야만 알 수 있음)

- 케이스별로 mapper 만들어야 할 수도 있음(아니면 동적 쿼리 이용)
객체답게 모델링 할수록 매핑 작업만 늘어난다.
객체 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?
그 해결책으로 나온 것이 JPA
JPA(JAVA Persistence API)
- 자바 진영의 ORM 표준
- ORM
- Object-relational mapping(객체 관계 매핑)
- 객체는 객체대로 설계
- 관계형 데이터베이스는 관계형 데이터베이스대로 설계
- ORM framework가 중간에서 mapping
- 대중적인 언어에는 대부분 ORM이 존재
- JPA는 애플리케이션과 JDBC 사이에서 동작

- 내가 직접 날리지않고 JPA 시킨다라고 생각
JPA 동작 - 저장

jpa.persist(member); //저장
JPA 동작 - 조회

`Member member = jpa.find(memberId); //조회
왜 JPA를 사용해야하는가?