대부분 데이터 접근 계층은 일명 CRUD로 같은 코드를 반복 개발해야 한다. JPA를 사용하여 이 같은 문제가 발생한다. 회원 리포지토리와 상품 리포지토리가 하는 일이 비슷하다. 이런 문제를 해결하려면 제네릭과 상속을 적절히 사용해서 공통 부분을 처리하는 부모 클래스를 만들면 된다. 이것을 GenericDAO라 한다. 이 방법은 공통 기능을 구현한 부모 클래스에 너무 종속되고 구현 클래스 상속이 가지는 단점에 노출된다. 1. 스프링 데이터 JPA 소개 데이터 접근 계층을 개발할 때 구현 클래스 없이 인터페이스만 작성해도 개발을 완료할 수 있다. 일반적 CRUD 메서드는 JpaRepository 인터페이스가 공통으로 제공하므로 문제가 없다. 그런데 MemberRepository.findByUsername{..

회원기능 - 회원 등록 - 회원 조회 상품 기능 - 상품 등록 - 상품 수정 - 상품 조회 주문 기능 - 상품 주문 - 주문 내역 조회 - 주문 취소 이 순서대로 개발하겠습니다. 다음 기능은 구현하지 않겠습니다. 로그인과 권한 관리는 하지 않는다. 파라미터 검증과 예외 처리는 하지 않는다. 상품은 도서만 사용한다. 카테고리는 사용하지 않는다. 배송 정보는 사용하지 않는다. 1. 개발 방법 Controller : MVC 컨트롤러가 모여 있는 곳이다. 컨트롤러는 서비스 계층을 호출하고 결과를 뷰(JSP)에 전달한다. Service : 서비스 계층에는 비즈니스 로직이 있고 트랜잭션을 시작한다. 서비스 계층은 데이터 접근 계층인 리포지토리를 호출한다. Repository : JPA를 직접 사용하는 곳은 리포지토..

1. 요구사항 분석 회원기능 - 회원 등록 - 회원 조회 상품 기능 - 상품 등록 - 상품 수정 - 상품 조회 주문 기능 - 상품 주문 - 주문 내역 조회 - 주문 취소 기타 요구사항 - 상품의 종류는 도서, 음반, 영화가 있다. - 상품을 카테고리로 구분할 수 있다. - 상품 주문 시 배송 정보를 입력할 수 있다. 2. 도메인 모델 설계 다대다 테이블은 관계형 DB, 엔티티에서도 거의 사용하지 않는다 따라서 일대다 , 다대일 관계로 풀어냈다. 상품 분류 : 상품은 도서, 음반, 영화로 구분되는데 상품이라는 공통 속성을 사용하므로 상속 구조로 표현했다. 3, 테이블 설계 MEMBER : 회원 엔티티의 Address 임베디드 타입 정보가 회원 테이블에 그대로 들어갔따. 이것은 DELIVERY 테이블도 마찬..

웹 애플리케이션 만들기 진행 순서 프로젝트 환경설정 도메인 모델과 테이블 설계 애플리케이션 기능 구현 프로젝트 환경설정 프로젝트 구조 메이븐과 사용 라이브러리 관리 - pom.xml 분석 라이브러리 간에 충돌을 피하려면 groupId + artifactId는 유일해야 한다. 에는 사용할 라이브러리를 지정한다. groupId + artifactId + version만 적어주면 메이븐 저장소에서 자동으로 내려받아 라이브러리에 추가해준다. 핵심 라이브러리는 다음 3가지 이다. 스프링MVC : 스프링 MVC 라이브러리 스프링ORM : 스프링 프레임워크와 JPA를 연동하기 위한 라이브러리 JPA, 하이버네이트 : JPA 표준과 하이버네이트를 포함하는 라이브러리 기타 라이브러리 H2 DB 커넥션 풀 : tomcat..

5. 네이티브 SQL JPQL은 표준 SQL이 지원한ㄴ 대부분의 문법과 SQL 함수들을 지원하지만 특정 DB에 종속적인 기능은 지원하지 않는다. 예를들어 특정 DB만 지원하는 함수, 문법, SQL 쿼리 힌트 인라인 뷰(From 절에서 사용하는 서브쿼리), UNION, INTERSECT 스토어드 프로시저 특정 DB에 종속적인 기능을 지원하는 방법은 다음과 같다. 특정 DB만 사용하는 함수 - JPQL에서 네이티브 SQL 함수 호출 가능 - 하이버네이트는 DB 방언에 각 DB에 종속적인 함수를 정의, 호출할 함수를 정의할 수 있다. 특정 DB만 지원하는 SQL 쿼리 힌트 - 하이버네이트를 포함한 몇몇 JPA 구현체들이 지원한다. 인라인뷰, UNION, INTERSECT - 하이버네이트는 지원하지 않지만 일부..

4. QueryDSL Criteria는 너무 어렵고 복잡하다. 쿼리를 문자가 아닌 코드로 작성해도, 쉽고 간결하며 그 모양도 쿼리와 비슷하게 개발할 수 있는 프로젝트가 바로 QueryDSL이다. QueryDSL도 Criteria처럼 JPQL 빌더 역할을 하는데 JPA Criteria를 대체할 수 있다. QueryDSL은 오픈소스 프로젝트이고 지금은 JPA, JDO, JDBC, Lucene, Hibernate Search, 몽고 DB, 자바 컬렉션 등을 다양하게 지원한다. 참고로 QueryDSL은 데이터를 조회하는데 기능이 특화되어 있다. QueryDSL 설정 - 필요 라이브러리 querydsl-jpa : QueryDSL JPA 라이브러리 querydsl-apt: 쿼리 타입(Q)을 생성할 때 필요한 라이브..

3. Criteria Criteria 쿼리는 JPQL을 자바 코드로 작성하도록 도와주는 빌더 클래스 API이다. 이것을 사용하면 문자가 아닌 코드로 JPQL을 작성하므로 문법 오류를 컴파일 단계에서 잡을 수 있고 문자 기반의 JPQL보다 동적 쿼리를 안전하게 생성할 수있다는 장점이 있다. 하지만 실제 Criteria를 사용해보면 복잡해서 직관적으로 이해가 힘들다는 단점이 있다. Critera는 결국 JPQL의 생성을 돕는 클래스 모음이다. Criteria 기초 Criteria API는 javax.persistence.criteria 패키지에 있다. Criteria 쿼리를 생성하려면 먼저 Criteria 빌더를 얻어야 한다. 이 빌더는 EntityManager나 EntityManagerFactory 에서 ..

1. 객체지향 쿼리 소개 EntityManager.find() 메서드를 사용하면 식별자로 엔티티 하나를 조회할 수 있다. 이렇게 조회한 엔티티에 객체 그래프 탐색을 사용하면 연관된 엔티티들을 찾을 수 있다. 이 둘은 가장 단순한 검색 방법이다. 식별자로 조회 : EntityManager.find() 객체 그래프 탐색 : ex) a.getB() 하지만 이 기능만으로 애플리케이션을 개발하기는 어렵다. ex) 나이가 30살 이상인 회원을 모두 검색하고 싶다. 그렇다고 모든 회원 엔티티를 메모리에 올려두고 검색하는 것은 현실성이 없다. 결국 데이터는 DB에 있으므로 SQL로 필요한 내용을 최대한 걸러서 조회해야 한다. 하지만 ORM을 사용하면 엔티티 객체를 대상으로 개발하므로 검색도 테이블이 아닌 엔티티 객체를..

JPA 데이터 타입은 크게 2종류이다.(엔티티타입, 값타입) 엔티티 타입(식별자를 통해 지속해서 추적 가능) @Entitiy로 정의하는 객체 값 타입(식별자가 없고 숫나나 문자같은 속성만 있으므로 추적 불가능) 기본값 타입 - 자바 기본 타입(int, double) - 래퍼 클래스(Integer) - String 임베디드 타입(복합 값 타입) 컬렉션 값 타입 비유를 하자면 엔티티 타입은 생물이고, 값 타입은 단순히 수치 정보다. 1. 기본값 타입 위에서 String, int가 값 타입이다. id라는 식별자 값도 가지고 생명주기도 있지만 name, age속성은 식별자 값도 생명주기도 회원 엔티티에 의존한다.따라서 회원 엔티티 인스턴스를 제거하면 name, age값도 제거된다. 2. 임베디드 타입(복합 값 ..

1. 프록시 위 회원 정보만 출력하는 로직에서 em.find()로 회원 엔티티를 조회할 때 회원과 연관된 팀 엔티티까지 DB에서 함께 조회해 두는 것은 효율적이지 않다. JPA는 이런 문제를 해결하려고 엔티티가 실제 사용될때까지 DB 조회를 지연하는 방법을 제공하는데 이것을 지연 로딩이라고 한다. 그런데 지연 로딩을 사용하려면 실제 엔티티 객체 대신에 DB조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 한다. 프록시 기초 JPA에서 식별자로 엔티티 하나를 조회할 때는 EntityManager.find()를 사용한다. 이 메서드는 영속성 컨텍스트에 엔티티가 없으면 DB를 조회한다. 이렇게 조회하면 엔티티를 실제 사용하든 사용하지 않든 DB를 조회하게 된다. 엔티티를 실제 사용하는 시점까지..