수학과의 개발자 도전기

1. 엔티티를 API에 노출하는 방법을 사용한다면 안되는 이유

-엔티티에 프레젠테이션 계층을 위한 로직이 추가된다

-엔티티에 API 검증을 위한 로직(@NotEmpty)이 들어간다

이는 엔티티에 validation을 위한 로직을 포함하는 것이다 

-실무에서는 회원 엔티티를 위해 다양한 API가 만들어지는데, 한 엔티티에 각 API의 모든 요청 요구사항을 담기는 어렵다

-엔티티가 변하면 API 스펙이 변한다(가장 큰 문제점)

-엔티티를 파라미터로 받아서 사용하는 saveMemberV1 메소드

@PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member)
{
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
   
}
 
 
@Data
    static class CreateMemberResponse {
    private Long id;
        
   public CreateMemberResponse(Long id) {   
		this.id = id;
              
     } 
}

---> 엔티티를 파라미터로 받지 말자. 엔티티를 노출해서도 안된다 

2. 위 문제를 해결하는 방법

API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다 

CreateMemberRequest를 Member 엔티티 대신에 RequestBody와 매핑한다

이렇게 하면, 

엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다

엔티티를 변경해도 API 스펙이 변하지 않는다 

엔티티와 API 스펙을 명확하게 분리할 수 있다 

@PostMapping("/api/v2/members")
      public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request) {
  
          Member member = new Member();
          member.setName(request.getName());
          Long id = memberService.join(member);
          return new CreateMemberResponse(id);
          
}

@Data
    static class CreateMemberRequest {
        private String name;
    }
    
@Data
static class CreateMemberResponse { 
	private Long id;
    public CreateMemberResponse(Long id) {
    	this.id = id;                 		 
}

1. createForm 

 @GetMapping(value = "/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";
      }

주문 폼 이동

메인 화면에서 상품 주문을 선택하면 /order를 GET 방식으로 호출한다 

주문에는 상품정보와 회원정보를 가져와야하므로 members,items 인스턴스를 생성한다 

그다음 model 객체를 통해 해당 인스턴스들을 view에 넘긴다 

2. order()

@PostMapping(value = "/order")
      public String order(
      @RequestParam("memberId") Long memberId,
      @RequestParam("itemId") Long itemId, 
      @RequestParam("count") int count) {
      
          orderService.order(memberId, itemId, count);
          return "redirect:/orders";
      }
}

주문할 회원과 상품 그리고 수량을 선택해서 submit 버튼을 누르면 /order URL을 POST방식으로 호출 

컨트롤러의 order() 메서드를 실행

이 메서드는 memberId(고객 식별자), itemId(주문할 상품 식별자), count(수량) 정보를 받아서 주문 서비스에 주문을 요청

주문이 끝나면 상품 주문 내역이 있는 /orders URL로 리다이렉트 

공부

1. @RequestParam:  http://127.0.0.1?index=1&page=2.  와 같은 형식의 URL에서 사용하는 어노테이션이다

URL 뒤에 붙은 파라미터 값을 가져올 때 사용한다 

/memberId=x & itemId=xx & count=xxx에서 x,xx,xxx의 값을 가져오는 것이라 이해하면 되려나?

2. redirect: 해당 URL로 다시 이동하게 해준다

3. orderList()

@GetMapping(value = "/orders")
      public String orderList(@ModelAttribute("orderSearch") OrderSearch orderSearch, Model model) {
          
          List<Order> orders = orderService.findOrders(orderSearch);
          model.addAttribute("orders", orders);
          return "order/orderList";
      }
}

4. cancelOrder()

@PostMapping(value = "/orders/{orderId}/cancel")
      public String cancelOrder(@PathVariable("orderId") Long orderId) {
      
          orderService.cancelOrder(orderId);
          return "redirect:/orders";
 } 
}

-준영속 엔티티: 영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.

em.detach()로 영속상태가 아닌 엔티티도 준영속 엔티티이고,

db에 저장되어서 식별자를 가지고 있는 엔티티도 준영속 엔티티로 볼 수 있다. 

준영속 엔티티를 수정하는 데에는 2가지 방법이 있는데,

1. 변경 감지(dirty checking) 기능 사용

2. 병합(merge) 사용

1. 변경감지 

영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법

트랜잭션 안에서 엔티티를 다시 조회하고, 변경할 값을 선택하면 트랜잭션 커밋 시점에 변경을 감지한다(Dirty Checking)이 

동작해서 데이터베이스에 UPDATE SQL을 실행한다 

@Transactional //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
void update(Item itemParam) { 

//같은 엔티티를 조회한다.
Item findItem = em.find(Item.class, itemParam.getId()); 

//데이터를 수정한다.
findItem.setPrice(itemParam.getPrice());}

2. 병합: 준영속 상태의 엔티티를 영속 상태로 변경할 때 사용하는 기능이다 

@Transactional //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
void update(Item itemParam) { 
	Item mergeItem = em.merge(item);
}

동작 방식

1. merge(member)를 실행

2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다

만약 1차 캐시에 해당 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다 mergeMember

3. 조회한 영속 엔티티 mergeMeber에 member 엔티티 값을 채워넣는다(member 엔티티의 모든 값을 mergeMember에 밀어 넣는다. 이때 mergeMember의 '회원1'이라는 이름이 '회원명변경'으로 바뀐다)

4. 영속 상태인 mergeMember를 반환한다 

===> 정리하자면

1. 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한다

2. 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다(병합한다)

3. 트랜잭션 커밋 시점에 변경감지 기능이 동작해서 데이터베이스에서 UPDATE SQL이 실행된다 

여기서 주의해야할 점이, 병합을 사용하면 모든 필트를 교체하기 때문에 만약 변경하지 않은 값이 있다면 null로 업데이트가 될 위험이 있다

ItemRepository

public void save(Item item) {
            if (item.getId() == null) {
                em.persist(item);
            } else {
                em.merge(item);
         }
    }

save() 메서드는 식별자 값이 없으면 새로운 엔티티로 판단해서 영속화하고, 식별자가 있으면 병합한다.

ItemController에서는 item이 준영속 상태이므로 식별자가 있기 때문에 merge()를 진행한다 

참고

실무에서는 보통 업데이트 기능이 매우 제한적이다. 그런데 병합은 모든 필드를 변경해버리고, 데이터가 없으면 null로 업데이트 해버린다.

병합을 사용하면서 이 문제를 해결하려면, 변경 폼 화면에서 모든 데이터를 항상 유지해야 한다. 

실무에서는 보통 변경 가능한 데이터만 노출하기 때문에, 병합을 사용하는 것이 오히려 번거롭다 

따라서, 엔티티를 변경할 때는 항상 변경 감지를 사용하자 

컨트롤러에서 어설프게 엔티티를 생성하지 말기

트랜잭션이 있는 서비스 계층에 식별자와 변경할 데이터를 명확하게 전달하기

트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하기

트랜잭션 커밋 시점에 변경 감지가 실행되어 UPDATE SQL 쿼리를 날린다

ItemController

1. createForm()

 @GetMapping(value = "/items/new")
      public String createForm(Model model) {
          model.addAttribute("form", new BookForm());
          return "items/createItemForm";
      }

2. create()

@PostMapping(value = "/items/new")
      public String create(BookForm form) {
          Book book = new Book();
          book.setName(form.getName());
           book.setPrice(form.getPrice());
          book.setStockQuantity(form.getStockQuantity());
          book.setAuthor(form.getAuthor());
          book.setIsbn(form.getIsbn());
          itemService.saveItem(book);
          return "redirect:/items";
      }

3. list()

 @GetMapping(value = "/items")
      public String list(Model model) {
          List<Item> items = itemService.findItems();
          model.addAttribute("items", items);
          return "items/itemList";
}

상품 수정

3. updateItemForm ()

@GetMapping(value = "/items/{itemId}/edit")
    public String updateItemForm(@PathVariable("itemId") Long itemId, Model
model) {
        Book item = (Book) itemService.findOne(itemId); //상품 아이디로 책 객체를 받아온 다음에
        
        //새로 생성한 인스턴스 form에 item의 정보들을 입력한다 
        BookForm form = new BookForm();
        form.setId(item.getId());
        form.setName(item.getName());
        form.setPrice(item.getPrice());
        form.setStockQuantity(item.getStockQuantity());
        form.setAuthor(item.getAuthor());
        form.setIsbn(item.getIsbn());
        
        model.addAttribute("form", form);
        return "items/updateItemForm";
    }

수정할 객체의 정보들을 화면에 보내는 메서드이다 

@PathVariable: url에서 각 구분자에 들어오는 값을 처리해야 할 때 사용한다

4. updateItem()

/ItemController

@PostMapping(value = "/items/{itemId}/edit")
        public String updateItem(@ModelAttribute("form") BookForm form) {
            //updateItem을 service계층에서 따로 생성한다 
            itemService.updateItem(form.getId(), form.getName(), form.getPrice());
            return "redirect:/items";
        }
}

병합 했을 때 문제점 때문에 변경감지하는 방식으로 메소드를 구현하고 컨트롤러에 적용했다 

병합에 관련한 포스트는 다음을 참고하면 된다

https://heyazoo1007.tistory.com/323

/ItemService

@Transactional
      public void updateItem(Long id, String name, int price) {
          Item item = itemRepository.findOne(id);
          item.setName(name);
          item.setPrice(price);
 } 
}

set을 한 후 트랜잭션 커밋 시점에 변경감지가 되어서 업데이트 쿼리를 날린다