Order에서 crateOrder 만들기

Order 클래스에서 static으로 자기 자신을 만들어서 반환하는 메서드

밖에서 order를 new 해서 생성하는 방식이 아니라,set,set,set 방식이 아니라, 생성을 할때 부터 createOrder를 호출하여 주문 생성에 대한 복잡한 비즈니스로 완결, 주로 생성과 고칠게 있다면 여기만 앞으로 생성하려면, 이거만 변경하면 된다.

동적 쿼리를 해결하기 위해서는?

1)JPQL 로 처리
2)JPA Criteria로 처리->치명적 단점 유지보수성 쓰레기
3)QueryDSL 로 처리

웹 계층 개발

@NotEmpty(message="gsgs")

필드를 입력 안했을때 나오는 메시지를 설정할 수 있다.
값이 비어있으면 오류 나게
회원이름을 필수로 하고 싶기 때문에 @PostMapping 에 @Valid MemberForm form 을 해주고 ,BindingResult result에 오류가 담긴다.

멤버폼이라는 빈 껍데기를 가져가는 이유?

->Validation 을 위해서

멤버 객체들을 출력하는 화면을 만들때는...

DTO 를 변환해서 화면에 꼭 필요한 것만 출력하는 것을 권장한다

타임리프 문법

th:object=${memberForm}-> 이 안에서 memberForm 객체를 쓰겠다는 것을 의미한다.
th:field="*{name}-> *표시: object를 참고하라는 말->Getter,Setter를 통한 프로퍼티 접근법을 의미한다.
th:field: 이름을 가지고 ID와 Name을 맞춘다 (html에서) id="city" name="city"

Entity vs 폼 객체

템플릿 엔진에서는 member의 객체를 막 써도 좋으나
API를 만들때는 Entity를 넘기지 말자. 왜? API 스펙이 변한다.
또한 실무에서 엔티티는 핵심 비즈니스 로직만 가지고 있고,화면을 위한 로직은 없어야 한다
화면이나 API에 맞는 폼객체나 DTO를 사용해도록 하자.

PathVariable

사용예: @GetMapping(value="/items/{itemId}/edit"}

더티체킹이란?

트랜잭션 안에서 Entity를 조회해야 영속상태로 조회한다. 후에 변화를 추적하는 것을 더티체킹이라 함

변경감지 vs merge

일단 기본적으로 준영속 엔티티라는 것이 있다.
준영속 엔티티란 영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.
DB에 한번 저장된 것이 영속성 컨텍스트에서 더는 관리하지 않을때와
임의로 만들어낸 엔티티가 기존 식별자를 가지고 있으면 준영속 엔티티라 볼 수 있다.

준영속 엔티티를 수정하는 방법

1.변경 감지 기능 사용
2.병합( merge ) 사용

1.변경 감지

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

위와 같이 영속성 컨텍스트에서 엔티티를 조회한 후에 데이터를 수정하고 트랜잭션 커밋 시점에 변경 감지를 통해 update sql 이 나간다.

2.병합 사용

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

위는 병합의 동작 방식을 나타낸 그림이다.

merge를 실행하면
준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회하고 만약 없다면 DB에서 엔티티 조회후 1차 캐시에 저장한다.

조회한 영속 엔티티(mergeMember)에 member를 밀어 넣는다. 그 후 영속 상태인 merge Member를 반환하는데
단점이 있다.

영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체하기 때문에 즉 병합은 모든 필드를 변경해 버리기 때문에 만일 실수로 특정 필드의 데이터를 없이 넣는다면 NULL이 들어가고 특정 데이터만 수정하고 싶을 때 번거롭다

따라서

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

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

update data가 많다면?

DTO 생성해서 처리하라.

컨트롤러안에서는 웹 관련 내용만!

Controller 안에서 지지고 볶고 해도 되지만 service 에서 Transaction안에서 하는게 할 수 있는게 더 많고, 영속 상태로 흘러 가기 때문에 깔끔한 문제 해결