⁉JDBC API를 사용해서 SQL를 전달 할때 예시
💨 이렇듯 객체를 DB에 CRUD 하려면 비슷하게 많은 코드를 작성해야한다.
만약 컬럼이 하나 추가 된다면?
해당 내용에 관련된 모든 소스코드에 컬럼명이 들어가야 할 것이다.
또한 변경하다가 실수로 ERROR가 발생한다면 코드를 까보고, 오타나 수정부분을 찾아내야한다.
책에서 말하는 애플리케이션에서 SQL을 직접 다룰때 발생하는 문제점은 다음과 같다.
- 진정한 의미의 계층분할이 어렵다.
- 엔티티를 신뢰할 수 없다.
- SQL에 의존적인 개발을 피하기 어렵다.
위의 컬럼이 하나 추가되는 상황처럼 만약 에러가 발생한다면,
모든 소스를 확인하고(계층분할), 데이터 전달 객체를 신뢰하고 사용할수 없으며(엔티티 신뢰), 결국 직접 SQL을 수정해야한다(SQL에 의존적).
❓ 복잡성을 제어하지 못하면 유지보수성이 감소한다.
스파게티 코드를 수정한다 할 때 쉬울까? 어려울까?
비즈니스 요구사항을 정의한 도메인 모델도 객체로 모델링하면, 객체지향 언어가 가진 장점들을 활용할 수 있다.
💨 하지만 저장시에 문제가 발생한다. 객체 인스턴스를 생성후 데이터를 영구히 보관할 공간이 필요하다.
이를 위한 현실적인 대안은 관계형데이터베이스에 저장하는 것 인데, 데이터중신으로 구조되어 있고, 추상화, 상속 다형성같은 개념이 없다.
💨 이를 패러다임의 불일치 문제라 하며, 객체 구조를 테이블 구조에 저장하는 것은 한계가있다.
💨문제는 이런 DB 사이의 패러다임 불일치 문제를 해결하는데 많은 시간과 코드를 사용중이라는 점이다.
이것을 해결하기 위한 결과물이 JPA이다.
ORM?
Object Relation Mapping으로 객체와 관계형 데이터베이스를 매핑한다는 뜻
=> 패러다임 불일치 문제를 개발자 대신 해결해준다.
ex) 하이버네이트
JPA는 자바 ORM 기술에 대한 표준 명세이다.
=> 인터페이스를 모아둔 것으로 JPA를 사용하려면 JPA를 구현한 ORM 프레임워크를 사용해야한다.
EX) jpa.persist(Member);
Member member = jpa.find(memberId);
위의 예시처럼 자바 컬렉션에 객체를 저장하듯이 JPA에 저장할 객체를 전달하기만 하면 된다.
◻ 반복적인 코드와 sql 작성을 줄일수있으며, JPA 안의 기능들을 사용하면 DB 설계 중심에서 객체 설계 중심으로 패러다임을 역전 시킬수 있다.
◻ 개발자가 작성해야 했던 SQL과 JDBC API 코드를 JPA가 대신 처리해주므로 유지보수해야하는 코드 수가 줄어든다.
◻ JPA가 패러다임 불일치 문제를 해결해주므로 객체지향언어가 가진 장점을 활용해서 유지보수성이 좋은 도메인 모델을 편리하게 설계가 가능하다.
JPA는 APPLICATION과 DATABASE사이에서 다양한 성능 최적화 기회를 제공한다.
같은 회원을 두 번 조회 할 일 이 생긴다면,
JPA는 SQL을 한 번만 DB에 전달하고 회원 객체를 재사용하는등의 성능 차이가 있다.
관계형 DB는 같은 기능도 벤더마다 사용법이 다른 경우가 많다.
EX) 페이징 처리, AUTO INCREMENT 등등
JPA를 사용하면 특정 DB기술에 종속되지 않도록 사용이 가능하다.
추후 추가
자바 ORM 표준 JPA 프로그래밍 -김영한 저