It's easy, if you try

[SpringBoot] 스프링부트와 JPA 활용 섹션 7 - 변경 감지와 병합 본문

스프링

[SpringBoot] 스프링부트와 JPA 활용 섹션 7 - 변경 감지와 병합

s5he2 2023. 3. 8. 23:45
반응형
명심
API를 만들때는 엔티티를 반환하면 안된다 ! (정보유출, API 스펙 변화)

홈 화면

html 파일

<head th:replace="fragments/header :: header"> : jsp의 include 와 같다. 
fragments 폴더 내의 header.html 파일 내의 th:fragment="header"를 가져다 include 한다.

타임리프 기본설정

spring:
    thymeleaf:
      prefix: classpath:/templates/
      suffix: .html

반환한 문자( home )과 스프링부트 설정 prefix , suffix 정보를 사용해서 렌더링할 뷰( html )를 찾는다.

타임리프 layout 스타일

  • Include-style layouts
  • Hierarchical-style layouts

타임리프 문법

  • <td th:text="${member.address?.city}"></td>
    ?를 붙이면 null을 무시한다.
  • <tr th:each="item : ${items}">
    Controller에서 model.addAttribute("items", items); 를 통해 담아온 items를 하나씩 꺼내 사용

컨트롤러 코드

  • @GetMapping("items/{itemId}/edit") 이때 itemId는 @PathVariable("itemId") Long itemId <- 와 같은 형태의 파라미터로 받아와 사용한다.
  • return "redirect:/orders"; // 리다이랙트
    기본적으로 http 로 리다이랙트됨. (설정 할 수 있는지 ? )

Error Validation

  • 컨트롤러 함수에서@Valid + BindingResult result 를 파라미터로 받아오기 -> 오류를 result에 담는다.
    • result.hasErrors() 
    • html 파일에서 th:class="${#fields.hasErrors('name')}" 설정하면됨. 

폼 객체 vs 엔티티 직접 사용

요구사항이 정말 단순할 때는 폼 객체( MemberForm ) 없이 엔티티( Member )를 직접 등록과 수정 화면에서 사용해도 된다. 하지만 화면 요구사항이 복잡해지기 시작하면, 엔티티에 화면을 처리하기 위한 기능이 점점 증가한다. 결과적으로 엔티티는 점점 화면에 종속적으로 변하고, 이렇게 화면 기능 때문에 지저분해진 엔티티는 결국 유지보수하기 어려워진다.
실무에서 엔티티는 핵심 비즈니스 로직만 가지고 있고, 화면을 위한 로직은 없어야 한다. 화면이나 API에 맞는 폼 객체나 DTO를 사용하자. 그래서 화면이나 API 요구사항을 이것들로 처리하고, 엔티티는 최대한 순수하게 유지하자.
<div class="container">
	<div th:replace="fragments/bodyHeader :: bodyHeader"/>
	<form role="form" action="/members/new" th:object="${memberForm}" method="post">
		<div class="form-group">
            <label th:for="name">이름</label>
            <input type="text" th:field="*{name}" class="form-control" placeholder="이름을 입력하세요" th:class="${#fields.hasErrors('name')}? 'form-control fieldError' : 'form-control'">
            <p th:if="${#fields.hasErrors('name')}" th:errors="*{name}">Incorrect date</p>
		</div>
        
		<div class="form-group">
			<label th:for="city">도시</label>
			<input type="text" th:field="*{city}" class="form-control" placeholder="도시를 입력하세요"> 
        </div>
		
        <div class="form-group">
			<label th:for="street">거리</label>
			<input type="text" th:field="*{street}" class="form-control" placeholder="거리를 입력하세요">
		</div>

		<div class="form-group">
			<label th:for="zipcode">우편번호</label>
			<input type="text" th:field="*{zipcode}" class="form-control" placeholder="우편번호를 입력하세요">
        </div>
        
        <button type="submit" class="btn btn-primary">Submit</button>
    </form>
	<br/>
	<div th:replace="fragments/footer :: footer" />
</div> <!-- /container -->

 

변경 감지와 병합(merge) - 준영속 엔티티를 수정하는 2가지 방법

준영속 엔티티

영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.
(여기서는 itemService.saveItem(book) 에서 수정을 시도하는 Book 객체다. Book 객체는 이미 DB 에 한번 저장되어서 식별자가 존재한다. 이렇게 임의로 만들어낸 엔티티도 기존 식별자를 가지고 있으면 준영속 엔티티로 볼 수 있다.)

변경 감지로 준영속 엔티티 수정하기

@Transactional
void update(Item itemParam) { //itemParam: 파리미터로 넘어온 준영속 상태의 엔티티
    Item findItem = em.find(Item.class, itemParam.getId()); //같은 엔티티를 조회한다.
	findItem.setPrice(itemParam.getPrice()); //데이터를 수정한다. 
}

영속성 컨텍스트에서 엔티티를 다시 조회한 후에 데이터를 수정하는 방법
트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택 -> 트랜잭션 커밋 시점에 변경 감지(Dirty Checking)가 동작해서 데이터베이스에 UPDATE SQL 실행

병합 사용으로 준영속 엔티티 수정하기

병합은 모든 속성을 변경하기 때문에  병합시 값이 없으면 null이 들어갈 수 있다.

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

병합 동작 방식

  1. merge()를실행한다.
  2. 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회한다.
  3. 2-1. 만약 1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고, 1차 캐시에 저장한다.
  4. 조회한 영속 엔티티( mergeMember )에 member 엔티티의 값을 채워 넣는다. (member 엔티티의 모든 바뀐다.)
  5. 값을 mergeMember에 밀어 넣는다. 이때 mergeMember의 “회원1”이라는 이름이 “회원명변경”으로
  6. 영속 상태인 mergeMember를 반환한다.

병합시 동작 방식을 간단히 정리

  1. 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한다.
  2. 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다.(병합한다.)
  3. 트랜잭션 커밋 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE SQL이 실행

병합을 사용하면서 null이 업데이트 되는 문제를 해결하려면, 변경 폼 화면에서 모든 데이터를 항상 유지해야 한다. 이는 변경가능한 데이터만을 주로 노출하는 실무에서 오히려 번거롭다. 이를 해결하기 위해서는 엔티티 변경시에 항상 변경감지를 사용하는 것이 좋다.

컨트롤러에서 어설프게 엔티티를 생성하지 마세요.
트랜잭션이 있는 서비스 계층에 식별자( id )와 변경할 데이터를 명확하게 전달하세요.(파라미터 or dto)
트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고, 엔티티의 데이터를 직접 변경하세요.
트랜잭션 커밋 시점에 변경 감지가 실행됩니다.
@Service
@RequiredArgsConstructor
public class ItemService {
	
    private final ItemRepository itemRepository;
    
    /**
    * 영속성 컨텍스트가 자동 변경
    */
    @Transactional
    public void updateItem(Long id, String name, int price, int stockQuantity)
    { // 식별자와 변경할 데이터 명확히 전달 받기
        Item item = itemRepository.findOne(id); // 영속 상태 엔티티 조회
        item.setName(name); // 엔티티 데이터 직접 변경
        item.setPrice(price);
        item.setStockQuantity(stockQuantity);
    }
}

-> 서비스 계층

반응형
저작자표시

'스프링' 카테고리의 다른 글

[SpringBoot] 스프링부트와 JPA 활용2 섹션 3 - 지연로딩과 조회 성능 최적화  (0) 2023.04.30
[SpringBoot] 스프링부트와 JPA 활용2 섹션 1 - API 개발  (0) 2023.03.13
[SpringBoot] 스프링부트와 JPA 활용 섹션 5, 6 - 도메인 개발 / JPA 동적 쿼리 (JPQL, JPA Criteria)  (1) 2023.03.02
[SpringBoot] 스프링부트와 JPA 활용 섹션 3, 4 - 어플리케이션 아키텍처/ 개발순서 / 엔티티, 리포지토리, 서비스, 테스트 작성  (1) 2023.02.19
[SpringBoot] 스프링부트와 JPA 활용 섹션 2 - 도메인 분석 설계 / Entity 클래스 작성  (1) 2023.02.15
'스프링' Related Articles more
Comments