이제 아이템을 주문할 때 창고에 있는 아이템 개수는 줄어들고, 주문목록엔 생겨나고, 장바구니 역할을 하는 OrderItem의 총 가격 등을 계산하고.. 같은 핵심 비즈니스를 해볼거다. @Entity @Table(name = "orders") @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) // protected로 생성자를 막음. createOrder를 사용하도록 함. public class Order { @Id @GeneratedValue @Column(name = "order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "member_id")..

별거 없다. 이론 설명은 전 섹션에서 다 했기 때문에. 처음 보는 개념으론 서비스가 아니고 왜 엔터티에 함수를 넣느냐이다. 이유는 엔터티 안의 변수를 직접적으로 다루는 거는 엔터티의 함수로 남겨놔야 유지보수가 편하다는 짬 섞인 경험이다. 그리고 좀 더 직관적이기도 하고. 커스텀 예외의 경우 순수성을 유지하기 위해 런타임으로 만든 듯 하다. 레퍼지토리는 db랑 직접 소통하는거고 전에 했어서 막 별거 없다. 볼만한건 merge로 아이템이 있어도 강제로 밀어붙이는거.

섹션3의 애플리케이션 구현 준비 이제 섹션 4에선 db랑 소통하는 레퍼지토리 짜고, 서비스 짜고, 이걸 테스트하는 코드를 짜본다. EntityManager를 저렇게 정의만 해도 lombok이 final 붙은건 가져오기끔 @RequiredArgsConstructor를 한다. 사실 이걸 위해 @Autowired쓰고 아니면 생성자에 붙이고.. 해야 되는데 계속 더 간단한 방법이 나온다. EntityManger의 createQuery의 특이점은 안의 내용이 결국은 sql문으로 변환되지만 여기선 모델이 아닌 엔터티를 받는다는데 있다. @Service @Transactional(readOnly = true) // 읽기 전용이면 성능이 좋아짐 @RequiredArgsConstructor // final이 있는 필드만..

쇼핑몰 만든건데 요구사항 이해한 내용이 너무 없는데, 이론편을 배우고 실전편을 배우는 걸로 진행을 해야 해서 그런 것 같다. 일단 이런게 필요하겠구나 하고 대략적으로 구성한 다음에 속성은 뭐가 필요할지, 그 속성이라면 테이블은 어떻게 할지 구체적으로 정하는 것 같다. 여기에서 강조한건 다대다는 운영에서 제약이 많기 때문에 안좋다. 또 양방향 관계도 양쪽이 서로를 참조하고 있어서 누가 주인인지 명시해야 해서 방침을 정하는 등 더 복잡해지고 이점은 단방향으로만 가능한 경우가 많아서 안하는게 좋다. 여기서 강조한건 외래키를 가지고 있는 애가 연관관계의 주인이라는 것. 다대일 에서 일쪽이 외래키를 가지고 있으려면 리스트 안에 등록하고 난리나니까 다쪽에 외래키로써 누가 주인인지 들고 있는게 db 구조다. 다대다 ..

섹션 0 이 강의해서 할건 게시판 실습 외에 실제로 부딪힐 만한 것들을 해볼거다. 1편은 위까지고 2편은 성능 최적화할거다. 섹션 1 start.spring.io를 통해 라이브러리를 3개정도 받았는데 보면 뭔가 많다. 이건 그 라이브러리를 실행하기 위한 다른 종속성 라이브러리들까지 합해서 들어오기 때문. 주목할만한건 HikariCP, slf4j, mvc고 start-web에 이미 tomcat이 들어있기 때문에 겸사겸사 다 같이 설치된 것. 테스트는 h2로. 테스트용으로 설치 및 사용이 편리하기 때문. https://spring.io/guides/gs/serving-web-content/ Getting Started | Serving Web Content with Spring MVC Static resou..

실제로 활용해보자. 회원 등록하는걸 예시로 만들어볼 거다. 원래 수정, 삭제 같은 경우도 로그로 남겨야 되지만 일단 등록할 때 실제 db에 회원 등록 및 로그도 등록하는걸 해볼거다. @Slf4j @Service @RequiredArgsConstructor public class MemberService { private final MemberRepository memberRepository; private final LogRepository logRepository; public void joinV1(String username) { Member member = new Member(username); Log logMessage = new Log(username); log.info("== memberRep..

여기선 트랜잭션 안에 트랜잭션이 있을 때, 트랜잭션이 2개일때 등 복잡한걸 해볼거다. 일단 status를 해서 트랜잭션 직접 시작하고 종료하는 것부터 해보자. @Slf4j @SpringBootTest public class BasicTxTest { @Autowired PlatformTransactionManager txManager; @TestConfiguration static class Config { @Bean public PlatformTransactionManager transactionManager(DataSource datasource) { return new DataSourceTransactionManager(datasource); } } @Test void commit() { log.in..

@Transaction쓰면 프록시를 만들어서 서비스 코드 순수성을 유지하는 방식이다. 프록시 클래스라서 AOP(Aspect Oriented Programming)이라고 하는데 코드 앞뒤로 계속 반복해서 사용할 수 밖에 없는걸 줄이자는 의미임. 이 강의는 좀 더 자세히 알아보자는 개념인듯. 실제로 프록시를 사용하는지 테스트코드 작성 package hello.springtx.apply; import lombok.extern.slf4j.Slf4j; import org.assertj.core.api.Assertions; import org.junit.jupiter.api.Test; import org.springframework.aop.support.AopUtils; import org.springframewo..

이건 가치관과 의견 차이에 대한 이야기인데, 이미 JpaRepository 자체가 알아서 잘 하고 있고 분리해서 만들기 위해 내가 사용할 Repository를 만들어서 JpaRepository를 상속해서 만드는데 어차피 JpaRepository를 사용하니 굳이 만들지 말고 서비스에서 바로 사용하는게 어떻겠느냐이다. 내가 JpaRepository를 상속하는용 레퍼지토리를 만들어서 사용하면 DB를 바꾸거나 하는데 더 간편하게 바꿀 수 있겠지만 사실 DB를 바꾸거나 할 일은 굳이 많지 않고 코드가 인터페이스 하나를 더 들어가야 해서 분석하는데 괜히 복잡해진다. 그럴바엔 그냥 서비스에서 바로 쓰는게 더 좋지 않느냐. 근데 서비스에서 바로 쓰면 안의 내용이 바뀌거나 하면 다 바뀌어야 해서 이것도 애매하다. 결론은..

querydsl의 제일 좋은 점은 타입체크가 가능해서 컴파일 에러를 띄울 수 있단거다. 이겟 무슨 말이냐면 일반 sql은 문자로 치게 되는게 문자로는 타입 에러를 띄울 수 없으니 런타임 에러로만 발견할 수 있고, 이러다보니 실제 사용자가 문제 발견해서 퇴근하다 돌아오고 하는 문제가 발생한다. 그럼 전까지 봤던 ORM이 자동으로 sql을 만들어서 하는건 알겠는데, 자동으로 작성하는 방법이 자기도 sql 문자로 변환해서 하던가, 아주 타입을 아주 어렵게 지정해서 하는 예전 EJB급이 있다. 그래서 이건 아니다 싶어 querydsl이 나왔다. 얘도 다양한 DB들을 같은 함수로 처리하고자 나왔다. 가장 큰 장점은 아까 말했듯 JPA, MongoDB, SQL 같은 기술들을 위해 type-safe SQL을 만드는 ..