package jpabook.jpashop.api;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import javax.validation.Valid;
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
Long join = memberService.join(member);
return new CreateMemberResponse(join);
}
@Data
static class CreateMemberResponse {
private Long id;
public CreateMemberResponse(Long id){
this.id = id;
}
}
}
postman에서 api test
파라미터로 데이터를 보내는 것이 아니기때문에 Body에서 raw, JSON 형식으로 바꿔준 후, name을 적어 POST 요청을 보내면 id 값이 1으로 정상적으로 동작하는 것을 볼 수 있습니다.
현재는 Entity에 아무런 제약조건을 걸지 않았기때문에 데이터를 넣지 않아도 @GeneratedValue를 설정한 PK를 제외한 모든 필드가 NULL로 만들어 집니다.
show_sql = true 설정으로 인해 발생한 쿼리문
위와 같이 NULL 값을 포함하지 않게 설정을 하고 싶다면 아래와 같이 @NotEmpty를 추가해주면 됩니다.
@NotEmpty 추가 후 돌리면 name에 값을 설정하지 않았기 때문에 에러가 발생한 것을 볼 수 있습니다.
알아야 할 점은 화면에 보여지는 계층을 presentation 계층이라 합니다. 현재 프레젠테이션 계층에 대한 검증 로직이 Member Entity에 추가가 된 것 입니다. 아무런 문제가 없어보이지만, 여기서 발생하는 문제가 있습니다.
두 개 이상의 api가 있을 때, 하나의 api에서는 @NotEmpty와 같은 검증 로직이 필요하지만 다른 하나의 api에서는 검증 로직이 필요가 없을 수도 있습니다.
Entity의 필드명을 바꿀 때, name으로 사용하고 있던 필드 명을 username으로 어떤 팀이 바꿨다고 가정해봅시다. 기존 api를 사용할 때 name으로 사용하던 코드들이 모두 정상작동하지 않게됩니다. 여기서 알아야할 점은 엔티티를 손보았을 때, api 스펙이 자체가 변하는 것이 문제입니다. Entity라는 것은 굉장히 여러 곳에서 사용하기 때문에 바뀔 확률이 높습니다. 그렇기 때문에, Entity를 손보아도 해당 Entity와 연관된 모든 api 스펙에 영향이 가지 않도록 설계하는 것이 중요합니다. 그렇기때문에 DTO 사용하는 습관을 길러야 합니다.
MemberApiController V2 추가
package jpabook.jpashop.api;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import javax.validation.Valid;
@RestController
@RequiredArgsConstructor
public class MemberApiController {
...
@PostMapping("/api/v2/members")
public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest createMemberRequest){
Member member = new Member();
member.setName(createMemberRequest.getName());
Long join = memberService.join(member);
return new CreateMemberResponse(join);
}
@Data
static class CreateMemberRequest{
private String name;
}
...
}
V2 장점
CreateMemberRequest라는 클래스를 만들어 name만 받도록 api를 설계했습니다. 위와 같이 설계하면 presentation 계층과 Entity 계층을 분리하기 때문에 유지보수가 편리해집니다.
V1처럼 Member를 파라미터로 두는 경우 알아서 바인딩되어 데이터가 들어가기 때문에 어떤 값이 들어오는지 알 수 없습니다. 하지만, V2의 경우 필요한 데이터만 필드를 만들기 때문에 들어가는 데이터를 알 수 있습니다.
검증 로직을 Entity에 추가하지 않고 DTO에 추가할 수 있습니다.
회원 수정 API
MemberApiController update 코드 추가
package jpabook.jpashop.api;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;
import javax.validation.Valid;
@RestController
@RequiredArgsConstructor
public class MemberApiController {
...
@PutMapping("/api/v2/member/{id}")
public UpdateMemberResponse updateMemberV2(
@PathVariable("id") Long id,
@RequestBody @Valid UpdateMemberRequest request){
memberService.update(id, request.getName());
Member findMember = memberService.findOne(id);
return new UpdateMemberResponse(findMember.getId(), findMember.getName());
}
@Data
static class UpdateMemberRequest{
private String name;
}
@Data
@AllArgsConstructor
static class UpdateMemberResponse{
private Long id;
private String name;
}
...
}
MemberService 코드 추가
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Member;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import jpabook.jpashop.repository.MemberRepository;
import java.util.List;
@Service
@RequiredArgsConstructor // final로 이루어진 필드로만 생성자를 만들어 줌
@Transactional(readOnly = true) //조회 성능 최적화
public class MemberService {
...
@Transactional
public void update(Long id, String name){
Member member = memberRepository.findOne(id);
member.setName(name);
}
}
회원에 대한 정보만 조회하려했지만, orders에 대한 정보도 포함되어 있는 것을 볼 수 있다.
@JsonIgnore라는 기능을 사용해서 포함시키지 않을 수 있다. 하지만, 위에서 말했듯 Entity는 다양한 api를 통해 호출을 한다. 하나의 api는 orders를 포함시키지 않아야하지만, 다른 하나의 api는 orders를 포함해야될 수 있다. 이러한 상황에서 문제가 생긴다.
/* Space out content a bit */
body {
padding-top: 20px;
padding-bottom: 20px;
}
/* Everything but the jumbotron gets side spacing for mobile first views */
.header,
.marketing,
.footer {
padding-left: 15px;
padding-right: 15px;
}
/* Custom page header */
.header {
border-bottom: 1px solid #e5e5e5;
}
/* Make the masthead heading the same height as the navigation */
.header h3 {
margin-top: 0;
margin-bottom: 0;
line-height: 40px;
padding-bottom: 19px;
}
/* Custom page footer */
.footer {
padding-top: 19px;
color: #777;
border-top: 1px solid #e5e5e5;
}
/* Customize container */
@media (min-width: 768px) {
.container {
max-width: 730px;
}
}
.container-narrow > hr {
margin: 30px 0;
}
/* Main marketing message and sign up button */
.jumbotron {
text-align: center;
border-bottom: 1px solid #e5e5e5;
}
.jumbotron .btn {
font-size: 21px;
padding: 14px 24px;
}
/* Supporting marketing content */
.marketing {
margin: 40px 0;
}
.marketing p + h4 {
margin-top: 28px;
}
/* Responsive: Portrait tablets and up */
@media screen and (min-width: 768px) {
/* Remove the padding we set earlier */
.header,
.marketing,
.footer {
padding-left: 0;
padding-right: 0;
}
/* Space out the masthead */
.header {
margin-bottom: 30px;
}
/* Remove the bottom border on the jumbotron for visual effect */
.jumbotron {
border-bottom: 0;
}
}
바뀐 페이지
회원 등록
MemberController PostMapping 추가
package jpabook.jpashop.controller;
import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.validation.BindingResult;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import javax.validation.Valid;
@Controller
@RequiredArgsConstructor
public class MemberController {
private final MemberService memberService;
// get 요청
@GetMapping("members/new")
public String createFrom(Model model){
// controller -> view 의 로직에서 data를 싫어서 보냄.
// memberForm에 저장된 데이터를 갖고옴 MemberFrom메 매핑하여
model.addAttribute("memberForm", new MemberForm());
return "members/createMemberForm";
}
// post 요청
@PostMapping("members/new")
public String create(@Valid MemberForm memberForm, BindingResult result){
// name을 필수로 입력해야하는데, 입력을 하지않아 에러가 존재한다면 다시 회원가입 페이지로 이동
if(result.hasErrors()){
return "members/createMemberForm";
}
Address address = new Address(memberForm.getCity(), memberForm.getStreet(), memberForm.getZipcode());
Member member = new Member();
member.setName(memberForm.getName());
member.setAddress(address);
memberService.join(member);
return "redirect:/";
}
}
post요청이 있다면, MemberForm에 입력 데이터를 파라미터로 가져옵니다. BindingResult는 에러가 있을경우 에러에대한 내용이 BindingResult로 넘어옵니다. 아래 MemberForm을 보시면 NotEmpty를 사용하여 Empty를 허용하지 않도록 했습니다. 그렇기때문에 이름이 null로 넘어올 경우 에러가 발생합니다. 이렇듯 에러가 발생하면 에러페이지를 띄우는 것이 아닌, 이름은 필수라는 문구와 함께 회원가입 페이지를 다시 띄워줍니다.
영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다. (아래에서는 itemService.saveItem(book)에서 수정을 시도하는 Book 객체이다. Book 객체는 이미 DB에 한번 저장되어서 식별자가 존재한다. 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준영속 엔티티로 볼 수 있다.)
준영속 엔티티를 수정하는 2가지 방법
변경 감지 기능 사용 (더티 체킹)
병합 (merge) 사용
변경 감지 기능 사용
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Item.Book;
import jpabook.jpashop.domain.Item.Item;
import jpabook.jpashop.repository.ItemRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.util.*;
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class ItemService {
...
@Transactional
public void updateItem(Long itemId, Book bookParam) {
Item findItem = itemRepository.findOne(itemId);
findItem.setPrice(bookParam.getPrice());
findItem.setName(bookParam.getName());
findItem.setStockQuantity(bookParam.getStockQuantity());
}
public List<Item> findItems(){
...
}
준영속 엔티티라 더티 체킹이 안될 것 같았지만, 해결책이 있었습니다.
트랜잭션 안에서 엔티티를 조회하여 영속 상태인 엔티티의 값을 변경해주면 됩니다. 이렇게하면 영속 상태이기 때문에 트랜잭션 커밋 시점에 변경 감지가 동작하여 update 쿼리문이 날라갑니다.
병합 사용
병합이란? 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능입니다.
병학 동작 방식
merge()를 실행한다.
파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.
만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한.
조회한 영속 엔티티(mergeMember)에 member 엔티티의 값을 채워 넣는다. (member 엔티티의 모든 값을 mergeMember에 밀어 넣는다. 이때, mergeMember의 "회원1" 이라는 이름이 "회원명변경"으로 바뀐다.)
영속 상태인 mergeMember를 반환한다.
주의 : 변경 감지 기능을 사용하면 원하는 속성만 선택해서 변경할 수 있지만, 병합을 사용하면 모든 속성이 변경된다. 따라서, 병합시 값이 없으면 null로 업데이트 할 위험도 있다. (병합은 모든 필드를 교체한다.)
결론 : merge는 모든 속성을 변경할 때만 사용하자.. (매우 위험) (되도록이면 변경감지를 사용하자)
엔티티를 변경할 때는 항상 변경 감지를 사용하세요
컨트롤러에서 어설프게 엔티티를 생성하지 마세요.
트랜잭션이 있는 서비스 계층에 식별자(primaryKey)와 변경할 데이터를 명확하게 전달하세요.
파라미터 or 데이터가 많다면 DTO를 생성해서 전달해주면 됩니다.
트랜잭션이 있는 서비스 게층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하세요.
트랜잭션 커밋시점에서 변경 감지가 실행됩니다.
상품 주문
OrderController
package jpabook.jpashop.controller;
import jpabook.jpashop.domain.Item.Item;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.repository.MemberRepository;
import jpabook.jpashop.service.ItemService;
import jpabook.jpashop.service.MemberService;
import jpabook.jpashop.service.OrderService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import java.util.*;
@Controller
@RequiredArgsConstructor
public class OrderController {
private final MemberService memberService;
private final OrderService orderService;
private final ItemService itemService;
@GetMapping("/order")
public String createForm(Model model){
List<Member> members = memberService.findMembers();
List<Item> items = itemService.findItems();
model.addAttribute("members", members);
model.addAttribute("items", items);
return "/order/orderForm";
}
@PostMapping("/order")
public String order(@RequestParam("memberId") Long memberId,
@RequestParam("itemId") Long itemId,
@RequestParam("count") int count) {
orderService.order(memberId, itemId, count);
return "redirectL/orders";
}
}
@RequestParam은 form submit 방식으로 select 에 지정한 name이랑 연관되는 이름 입니다.
package jpabook.jpashop.domain;
import lombok.Getter;
import lombok.Setter;
import java.time.LocalDateTime;
import java.util.*;
import javax.persistence.*;
@Entity
@Table(name = "Orders")
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 기본 생성자를 protected로 선언하여 다른 패키지의 클래스에서 빈생성자를 생성을 막음
public class Order {
...
//==생성 메서드==//
public static Order createOrder(Member member, Delivery delivery, OrderItem... orderItems){
Order order = new Order();
order.setMember(member);
order.setDelivery(delivery);
for(OrderItem orderItem : orderItems){
order.addOrderItem(orderItem);
}
order.setStatus(OrderStatus.ORDER);
order.setOrderDate(LocalDateTime.now());
return order;
}
//==비즈니스 로직==//
/**
* 주문 취소
*/
public void cancel(){
if(delivery.getDeliveryStatus() == DeliveryStatus.COMP){
throw new IllegalStateException("이미 배송완료한 상품은 취소가 불가능합니다.");
}
this.setStatus(OrderStatus.CANCLE);
for(OrderItem orderItem : orderItems){
orderItem.cancel();
}
}
//==조회 로직==//
/**
* 전체 주문 가격 조회
*/
public int getTotalPrice() {
return orderItems.stream()
.mapToInt(OrderItem::getTotalPrice)
.sum();
/*
위와 같은 코드
int totalPrice = 0;
for (OrderItem orderItem : orderItems) {
totalPrice += orderItem.getTotalPrice();
}
return totalPrice;*/
}
}
OrderItem Entity
package jpabook.jpashop.domain;
import jpabook.jpashop.domain.Item.Item;
import lombok.Getter;
import lombok.Setter;
import javax.persistence.*;
@Entity
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 기본 생성자를 protected로 선언하여 다른 패키지의 클래스에서 빈생성자를 생성을 막음
public class OrderItem {
...
//==생성 메서드==//
public static OrderItem createOrderItem(Item item, int orderPirce, int count){
OrderItem orderItem = new OrderItem();
orderItem.setItem(item);
orderItem.setOrderPirce(orderPirce);
orderItem.setCount(count);
item.removeStock(count);
return orderItem;
}
//==비즈니스 로직==//
public void cancel() {
getItem().addStock(count);
}
public int getTotalPrice(){
return getOrderPirce()*getCount();
}
}
주문 리포지토리 개발
OrderRepository
package jpabook.jpashop.repository;
import jpabook.jpashop.domain.Order;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import java.util.*;
import javax.persistence.EntityManager;
@Repository
@RequiredArgsConstructor
public class OrderRepository {
private final EntityManager em;
public void save(Order order){
em.persist(order);
}
public Order findOne(Long orderId){
return em.find(Order.class, orderId);
}
//후에 개발
//public List<Order> findAll(OrderSearch orderSearch) {}
}
주문 서비스 개발
OrderService
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Delivery;
import jpabook.jpashop.domain.Item.Item;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderItem;
import jpabook.jpashop.repository.ItemRepository;
import jpabook.jpashop.repository.MemberRepository;
import jpabook.jpashop.repository.OrderRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.util.*;
@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class OrderService {
private final OrderRepository orderRepository;
private final MemberRepository memberRepository;
private final ItemRepository itemRepository;
/**
* 주문
*/
@Transactional
public Long order(Long memberId, Long itemId, int count){
// 엔티티 조회
Member member = memberRepository.findOne(memberId);
Item item = itemRepository.findOne(itemId);
// 배송 정보 생성
Delivery delivery = new Delivery();
delivery.setAddress(member.getAddress());
// 주문 상품 생성
OrderItem orderItem = OrderItem.createOrderItem(item, item.getPrice(), count);
// 주문 생성
Order order = Order.createOrder(member, delivery, orderItem);
// 저장
orderRepository.save(order);
return order.getId();
}
/**
* 취소
*/
@Transactional
public void cancelOrder(Long orderId){
// 주문 엔티티 조회
Order order = orderRepository.findOne(orderId);
// 주문 취소 (비즈니스 로직을 만들어 놓았기 때문에, cancel 메소드만 접근하면 된다.)
order.cancel();
// jpa가 아니라면 수정된 데이터들을 update 쿼리문을 날려야하지만,
// jpa는 더티 체킹을 통해 변경된 내역을 알아서 update 쿼리문을 날린다.
// 정말 편리
}
/**
* 검색
*/
//public List<Order> findOrders(OrderSearch orderSearch){
// return orderRepository.findAll(orderSearch);
//}
}
jpa가 아니라면 order.cancel() 아래 코드에서 변경된 데이터에 대한 업데이트 쿼리문을 작성하여 DB에 날려야 하지만, jpa의 경우 더티체킹을 통해 기존의 데이터와 바뀐 데이터가 있다면 알아서 찾아내어 update 쿼리문을 날리기때문에 따로 update 쿼리문을 작성하여 날리지 않아도 됩니다!!! (정말 편리하네요..)
참고
엔티티에 핵심 비즈니스 로직을 적는 패턴을 "도메인 모델 패턴"이라고 부릅니다. "도메인 모델 패턴"은 서비스 계층을 단순히 엔티티에 필요한 요청을 위임하는 역할을 합니다.
반대로, 엔티티에는 비즈니스 로직이 거의 없고, 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 "트랜잭션 스크립트 패턴"이라고 합니다.
두 가지 방법이 있는 것은 어느 패턴이 더 뛰어나기 때문이 아닌 상황에 따라서, 유지 보수에 좋은 상황이 있기 때문입니다.
결론 : 상황에 따라서 유지 보수하기 편리한 패턴을 사용하자!
주문 기능 테스트
OrderServiceTest
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Item.Book;
import jpabook.jpashop.domain.Item.Item;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderStatus;
import jpabook.jpashop.exception.NotEnoughStockException;
import jpabook.jpashop.repository.OrderRepository;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.transaction.annotation.Transactional;
import javax.persistence.EntityManager;
import static org.junit.Assert.*;
@RunWith(SpringRunner.class)
@SpringBootTest
@Transactional
public class OrderServiceTest {
@Autowired
private EntityManager em;
@Autowired OrderService orderService;
@Autowired
OrderRepository orderRepository;
@Test
public void 상품주문() throws Exception {
//given
Member member = createMember();
Item book = createBook("영진 JPA", 10000, 10);
int orderCount = 2;
//when
Long orderId = orderService.order(member.getId(), book.getId(), orderCount);
//then
Order getOrder = orderRepository.findOne(orderId);
assertEquals("상품 주문시 상태는 ORDER", OrderStatus.ORDER,getOrder.getStatus());
assertEquals("주문한 상품 종류 수가 정확해야 한다.", 1, getOrder.getOrderItems().size());
assertEquals("주문 가격은 가격*수량이다.", 10000*orderCount, getOrder.getTotalPrice());
assertEquals("주문 수량만큼 재고가 줄어야 한다.", 10-orderCount, book.getStockQuantity());
}
@Test
public void 주문취소() throws Exception {
//given
Member member = createMember();
Item book = createBook("영진 JPA", 10000, 10);
int orderCount = 2;
Long orderId = orderService.order(member.getId(), book.getId(), orderCount);
//when
orderService.cancelOrder(orderId);
//then
Order getOrder = orderRepository.findOne(orderId);
assertEquals("상품 주문시 상태는 CANCEL", OrderStatus.CANCEL,getOrder.getStatus());
assertEquals("주문이 취소된 상품은 재고가 증가되야 한다.", 10, book.getStockQuantity());
}
@Test(expected = NotEnoughStockException.class)
public void 재고수량초과() throws Exception {
//given
Member member = createMember();
Item book = createBook("영진 JPA", 10000, 10);
int orderCount = 11;
//when
Long orderId = orderService.order(member.getId(), book.getId(), orderCount); // 여기서 예외가 터져야함.
//then
fail("재고 수량 부족 예외가 발생해야 한다.");
}
// 만들어 놓은 로직을 ctrl+alt+M 하면 메소드화 가능
private Item createBook(String name, int price, int stockQuantity) {
Item book = new Book();
book.setName(name);
book.setPrice(price);
book.setStockQuantity(stockQuantity);
em.persist(book);
return book;
}
private Member createMember() {
Member member = new Member();
member.setName("회원1");
member.setAddress(new Address("서울", "경기", "123-123"));
em.persist(member);
return member;
}
}
위의 코드는 DB와 연동해서 테스트를 하는 예제입니다.
참고
도메인 모델 패턴은 도메인 엔티티에 비즈니스 로직이 있기때문에 도메인으로만 로직이 정상적으로 작동하는지 테스트하는 것이 장점입니다. 이를 잘 활용하는 것이 도메인 모델 패턴을 보다 잘 살려내는 방법이라고 생각합니다. 이유는 DB와 연동하지 않기때문에 테스트가 빠르기 때문입니다.
주문 검색 기능 개발
JPA에서 동적 쿼리를 어떻게 해결해야 하는가?
JPA Criteria
유지보수성이 너무 떨어진다. 직접 쿼리를 작성해보면 무슨 쿼리가 작성되는지 머리로 그려지지 않기 때문입니다.
package repository;
import jpabook.jpashop.domain.Member;
import org.springframework.stereotype.Repository;
import java.util.*;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
@Repository // componentscan에 의하여 스프링 빈으로 관리됨
public class MemberRepository {
// PersistenceContext는 스프링이 생성한 EntityManager를 자동으로 주입시켜줌
@PersistenceContext
private EntityManager em;
public void save(Member member){
em.persist(member);
}
public Member findOne(Long id){
return em.find(Member.class, id);
}
public List<Member> findAll() {
return em.createQuery("select m from Member m", Member.class)
.getResultList();
}
public List<Member> findByName(String name){
return em.createQuery("select m from Member m where m.name = :name", Member.class)
.setParameter("name", name)
.getResultList();
}
}
@Repository는 @Component 스캔의 대상이기 때문에 자동으로 스프링 빈에서 관리합니다.
@PersistenceContext는 스프링이 생선한 EntityManager를 자동으로 주입시켜 줍니다.
참고로 EntityManagerFactory를 쓰고 싶다면 @PersistenceUnit을 사용하시면 됩니다.
회원 서비스 개발
MemberService
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Member;
import lombok.AllArgsConstructor;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import repository.MemberRepository;
import java.util.List;
@Service
@RequiredArgsConstructor // final로 이루어진 필드로만 생성자를 만들어 줌
public class MemberService {
private final MemberRepository memberRepository; // 한번 초기화하면 바꿀 일이 없으니 final 선언
/**
* 회원 가입
*/
@Transactional
public Long join(Member member){
validateDuplicateMember(member);
memberRepository.save(member);
return member.getId();
}
/**
* 같은 이름이 있는 회원은 등록 안되도록
*/
private void validateDuplicateMember(Member member) {
//exception
// 이러한 경우 멀티스레드 환경에서 문제가 될 수 있다.
// 방지하기 위해서 member의 name을 unique 제약조건을 거는 것을 권장한다.
List<Member> findMembers = memberRepository.findByName(member.getName());
if(!findMembers.isEmpty()){
throw new IllegalStateException("이미 존재하는 회원입니다.");
}
}
/**
* 회원 전체 조회
*/
@Transactional(readOnly = true) // 조회 성능 최적화
public List<Member> findMembers() {
return memberRepository.findAll();
}
/**
* 멤버 1명 조회
*/
@Transactional(readOnly = true) // 조회 성능 최적화
public Member findOne(Long memberId){
return memberRepository.findOne(memberId);
}
}
코드는 다르지만 같은 동작을 합니다. @RequiredArgsConstructor은 왼쪽의 코드 기능을 제공합니다.
Spring Data JPA를 사용하지 않는 경우 @PersistenceContext를 사용해야 bean에서 injection시켜주지만, Spring Data JPA를 사용하는 경우 @PersistenceContext를 사용하지 않고 @Autowired만 사용해도 injection 시켜줍니다.
따라서, MemberRepository를 아래와 같이 변경할 수 있습니다.
회원 기능 테스트
MemberServiceTest
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Member;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.transaction.annotation.Transactional;
import jpabook.jpashop.repository.MemberRepository;
import static org.junit.Assert.*;
@RunWith(SpringRunner.class) // "junit을 실행할 때, 스프링과 엮어서 실행하겠다"를 의미합니다.
@SpringBootTest // SpringBoot를 띄운 상태에서 Test를 할 때 추가해야되는 어노테이션 (추가하지 않으면 @Autowired기능에서 에러가 발생합니다.)
@Transactional // 기본적으로 rollback
public class MemberServiceTest {
@Autowired MemberService memberService;
@Autowired MemberRepository memberRepository;
@Test
// @Rollback(false) insert query 문을 보고싶다면 해보자
// 또는 EntityManager를 만들어서 flush() 해주면된다.
public void 회원가입() throws Exception {
//given
Member member = new Member();
member.setName("kim");
//when
Long saveId = memberService.join(member);
//then
assertEquals(member, memberRepository.findOne(saveId));
}
@Test(expected = IllegalStateException.class)
public void 중복_회원_예외() throws Exception {
//given
Member member1 = new Member();
member1.setName("kim");
Member member2 = new Member();
member2.setName("kim");
//when
memberService.join(member1);
memberService.join(member2); // 예외 발생해야 함.
//then
fail("예외가 발생해야 한다.");
}
}
given, when, then 이란?
"given을 주고 when 상황이 있을 때, then 이러한 결과가 나올 것이다."의 flow로 이어지는 테스트 작성 방법입니다.
In-Memory 설정하는 url이 있습니다. test를 할 땐 In-Memory로 하기위해
프로젝트 test 폴더에 resources 파일을 만들어 main에 있는 application.yml을 복사해서 저장해줍니다. 그리고 application.yml 코드 중 datasource url을 jdbc:h2:mem:test로 수정해주시면 In-Memory로 테스트를 할 수 있습니다.
참고로 Spring boot에서 database에 대한 별다른 설정이 없다면 memory DB로 돌리기 때문에 Database 설정에 대한 모든 코드를 지워도 memory 모드로 사용가능 합니다.
회원은 여러 상품을 주문할 수 있다. 그리고 한 번 주문할 때 여러 상품을 선택할 수 있으므로 주문과 상품은 다대다 관계다. 하지만 이런 다대다 관계는 관계형 데이터베이스는 물론이고 엔티티에서도 거의 사용하지 않는다. 따라서 그림처럼 주문상품이라는 엔티티를 추가해서 다대다 관계를 일대다, 다대일 관계로 풀어냈다.
상품 분류
상품은 도서, 음반, 영화로 구분되는데 상품이라는 공통 속성을 사용하므로 상속 구조로 표현했다.
회원 엔티티 분석
회원(Member)
이름과 임베디드 타입인 주소 (Address), 주문(orders) 리스트
주문(Order)
한 번 주문시 여러 상품을 주문할 수 있으므로 주문과 주문상품(OrderItem)은 일대다 관계, 주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태(Status)를 가지고 있습니다. 주문 상태는 열거형으로 사용했는데 주문(Order), 취소(Cancel)를 표현할 수 있습니다.
주문 상품(OrderItem)
주문한 상품 정보와 주문 금액(orderPrice), 주문 수량(count)
상품(Item)
이름, 가격, 재고수량(stockQuantity)
배송(Delivery)
주문 시 하나의 배송 정보를 생성합니다. 주문과 배송은 일대일 관계입니다.
카테고리(Category)
상품과 다대다 관계를 맺습니다. parent, child로 부모, 자식 카테고리를 연결합니다.
회원 테이블 분석
MEMBER
회원 엔티티의 Address 임베디드 타입 정보가 회원 테이블에 그대로 들어갔다. DELIVERY 테이블도 마찬가지.
ITEM
앨범, 도서, 영화 타입을 통합해서 하나의 테이블로 만들었다. DTYPE 컬럼으로 타입을 구분
참고 : 테이블명이 ORDER가 아니라 ORDERS인 것은 데이터베이스가 order by때문에 예약어로 잡고 있는 경우가 많기 때문입니다.
참고 : 실제 코드에서는 DB에 소문자 + _(언터스코어) 스타일을 사용 데이터베이스 테이블명, 컬럼명에 대한 관례는 회사마다 다르다.
연관관계 매핑 분석
회원과 주문
일대다, 다대일의 양방향 관계다. 따라서 연관관계의 주인을 정해야 하는데, 외래 키가 있는 주문을 연관관계의 주인으로 정하는 것이 좋다. 그러므로 Order.member를 ORDERS.MEMBER_ID 외래키와 매핑한다.
주문상품과 주문
다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다. 그러므로 OrderItem.order를 ORDER_ITEM.ORDER_ID 외래 키와 매핑한다.
@ManyToMany를 사용해서 매핑한다. (실무에서 @ManyToMany는 사용하지 말자. 여기서는 다대다 관계를 예제로 보여주기 위해 추가했을 뿐이다.)
참고 : 외래 키가 있는 곳을 연관관계의 주인으로 정해라. 연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.. 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래 키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능 한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. 자세한 내용은 JPA 기본편을 참고하자.
엔티티 클래스 개발
Member 엔티티
package jpabook.jpashop.domain;
import lombok.Getter;
import lombok.Setter;
import javax.persistence.*;
import java.util.*;
@Entity
@Getter
@Setter
public class Member {
@Id // pk
@GeneratedValue
@Column(name = "member_id")
private Long id;
private String name;
@Embedded
private Address address; // Address에 Embeddable을 추가하거나 Address사용할 때 Embedded 어노테이션 추가
@OneToMany(mappedBy = "member") // 연관관계 주인이 아님을 명시
private List<Order> orders = new ArrayList<>();
}
위의 코드를 추가한 뒤 실행하고 H2 콘솔에서 테이블을 확인해보면 위의 설계대로 테이블이 생성된 것을 확인할 수 있습니다.
생성된 테이블
참고 : 이론적으로 Getter, Setter 모두 제공하지 않고 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적입니다.
하지만, 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로 Getter의 경우 모두 열어두는 것이 편리합니다. Getter은 아무리 호출해도 어떤 일이 발생하지 않기 때문입니다. 하지만, Setter의 경우는 문제가 다릅니다. Setter를 호출하면 데이터가 변합니다. Setter를 막 열어두면 가까운 미래에 엔티티가 도대체 왜 변경되는지 추적하기 점점 힘들어집니다. 그래서 엔티티를 변경할 때는 Setter 대신에 변경지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 합니다. 그래야 유지보수성이 올라갑니다.
결론 : Getter 어노테이션은 추가하되, Setter는 지양
참고 : 실무에서는 @ManyToMany를 지양 (지양보다는 절대 사용하지 마라.)
@ManyToMany는 편리한 것 같지만, 중간 테이블(CATEGORY_ITEM)에 컬럼을 추가할 수 없고, 세밀하기 쿼리를 실행하기 어렵기 때문에 실무에서 사용하기에는 한계가 있다. 중간 엔티티 (CategoryItem을 만들고 @ManyToOne, @OneToMany로 매핑해서 사용하자)
결론 : 다대다 매핑 사용 X 필요 시 (다대다 => 일대다 + 다대일) 관계로 풀어내자
참고 : 위에서 사용한 Address와 같은 값 타입은 변경 불가능하게 설계해야 합니다.
@Setter를 제거하고, 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스를 만들자. JPA 스펙상 엔티티나 임베디드 타입(@Embeddable)은 자바 기본 생성자(default constructor)를 pulbic 또는 protected로 설정해야 한다. public 보다는 protected로 설정하는 것이 더 안전하다. >JPA가 이런 제약을 두는 이유는 JPA 구현 라이브러리가 객체를 생성할 때 리플렉션 같은 기술을 사용할 수 있도록 지원해야 하기 때문이다.
결론 : 값 타입의 경우 기본 생성자로만 변경이 가능하도록 설계하자.
엔티티 설계시 주의점
엔티티에는 가급적 Setter를 사용하지 말자.
Setter가 모두 열려있다면, 변경 포인트가 너무 많아 유지보수가 어렵다.
모든 연관관계는 지연로딩으로 설정
즉시로딩은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다.
실무에서 모든 연관관계는 지연로딩으로 설정해야 한다.
연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다.
@XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다.
컬렉션은 필드에서 초기화 하자
컬렉션은 필드에서 바로 초기화 하는 것이 안전하다.
null 문제에서 안전하다. (바로 초기화 시키기 때문)
하이버네이트는 엔티티를 영속화할 때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 getOrders() 처럼 임의의 메서드에서 컬렉션을 잘못 생성하면 하이버네이트 내부 메커니즘에서 문제가 발생할 수 있다.
따라서, 필드레벨에서 생성하는 것이 안전하고, 코드도 간결하다.
Member member = new Member();
System.out.println(member.getOrders().getClass());
em.persist(member);
System.out.pritnln(member.getOrders().getClass());
// 출력 결과
class java.util.ArrayList
class org.hibernate.collection.internal.PersistentBag
hibernate collection으로 감싸는 이유는 변경 감지(더티체킹)를 위해서 감싸야합니다. 한번 초기화만 해주는 이유는 hibernate에서 감쌋는데, 다시 초기화를 해버리면 hibernate에서 원하는대로 동작할 수 없기 때문입니다. 그렇기 때문에 되도록이면 바꾸지 않는 것을 권장합니다.
