실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션7. 웹 계층 개발

뷰를 위한 html들 넣어준다.. 볼만한건 fragments/header .. 로 이하로 한다는 거

 

form 받는거 구성

타임리프는 아니까 그냥 복습 겸... @Valid가 있으면 맞는지 검사하고 만약 바로 뒤의 매개변수로 bindingresult 있으면 에러 안띄우고 안에서 처리해서 다시 html에 넘길 수 있고 등..

 

리스트..

절대 주의할 점은 만약 api로 한다고 하면 저렇게 엔티티 자체를 그대로 넘기면 안된다. 지금은 실습이고 어차피 서버 사이드 렌더링이라 크게 상관 없어서 하는거지만. 하지만 서버 사이드 렌더링도 Dto를 만들어서 하는게 좋다.

 

 

아이템

 

상품목록

상품 수정은 위에서 수정용 링크로 가게 한다.

 

수정 해주는게 중요함.

 

그리고 save를 타고 가다보면 merge를 사용하는데 실무에선 거의 안쓴다고 함..

 

 

하지만 정말 정말 정말 중요한건 변경 감지와 병합의 차이를 알아야 한다. 100% 이해해야 한다. 사실 결론은 변경 감지 사용하라는 거다.

일단 변경 감지가 뭔지부터 알아보자.

이렇게 아이템을 업데이트 할 때, 잘 보면 뭐 persist나 save 같은거 없이 그냥 값만 변경한다. 하지만 적용된다. 이유는 EntityManager로 가져오면 이 변화를 계속 추적하는 객체가 붙어서 @Transactional 끝났을때 jpa가 flush를 해서 변화된 거 없나 한번 쭉 순회한 다음 변화되었다면 db에 바로 반영한다. 사실 전에 배웠던 거다.

문제는 EntityManager를 통해서 가져온게 아니라 내가 새로 new 해서 만든거라 추적하는 객체가 안 붙었을 때다.

새로운 아이템을 만든다고 new를 만들고 그 객체에 속성을 넣어가며 만드는 모습이다. 하지만 여기엔 그냥 쌩으로 내가 만들어서 하는것이기 때문에 추적하는 객체는 당연히 없을 것이고, 그러므로 save같은거 없이 @Transactional이 끝난다고 해도 뭐 변경을 추적할 수 있는게 없으니까 반영되지 않는다. 그래서 변경이라도 굳이 saveItem으로 저장 해주는 것. 하지만 여기서 saveItem을 하면 merge하도록 짜놓았다.

 

아이템이 이미 db에 있고 수정이 목적이기 때문에 merge를 했다.

그럼 merge란 무엇인가. 난 http의 put이랑 비슷하다고 느꼈다. 즉 하나만 바꾸면 그것만 적용되고 설정을 안해주면 나머지는 null이 되는 무시무시한 메소드다. 그래서 patch를 쓰듯이..

지금은 perge를 쓰고 있기 때문에 업데이트 한답시고 저렇게 속성 하나라도 놓지면 아주 그냥 난리나는거다. 그래서 저러지 말고 수정하고 싶은 부분만 가져와 수정하고 수정 반영은 변경 감지가 알아서 하도록 냅두는게 좋다는 것이다.

사실 perge도 까보면 위와 같이 동작한다. new로 새로 만든 객체를 db에 한번 담궜다 꺼내서 추적할 수 있는 객체로 만드는 것. 하지만 빼먹은 부분은 null이 되니 그냥 사용하지 말자.

 

다음은 가입한 사람이 있고, 등록된 상품이 있을 때 가입한 회원이 등록된 상품 중 하나를 골라 주문하는 로직

주목할 부분은 orderService에서 order를 받을 때 객체를 받는게 아닌 id 값 등의 고유 값을 가져오는 것. 이게 더 안전한 것도 있고 orderService 안에 order 객체 말고 다른것들도 막 들어오면 좀 불안해지는게 있다. 또 id를 받아오도록 하는 것이 테스트 할 때도 좋다.

 

주문 목록은 목록용 클래스 만들고 하면 된다. 머리를 잘 쓴 부분이 get 방식으로 받아 query를 사용해서 구분하는 거.

그리고 cancel하면 해당 내용이 반영되고 다시 redirect해서 목록을 보여준다. 정말 빨라 마치 실시간으로 되는 것 처럼 보여짐.