안녕하세요. @QueryHint 의 readOnly 속성과 관련하여 질문있습니다. 이전의 강의(jpa 활용 1편) 에서 service 단에 @Transaction(readOnly=true) 설정을 주었을 때 영속성 context flush (X), dirty checking (X) 를 통해서 성능을 최적화하고 DB에 읽기 전용임을 알린다고 배운게 기억이 나서요. 정리하자면  1. @QueryHint 의 readOnly 속성은 (how) 스냅샷을 만들지 않음으로써  (what) Dirty Checking의 비교를 하기 위해 내부적으로 객체를 2개(스냅샷) 만들어 메모리 낭비하는 것을 방지 2. @Transaction(readOnly=true) 속성은 (how) DB에 반영할 것이 없다는 것을 암시하여 영속성 context flush 를 하지 않도록 하여  (what) dirty checking 안 함 -> 성능 최적화 으로 이해를 했는데요. 왠지 두가지 방법이 매우 유사한 것 같아 이와 관련하여 구글링 하던 중  https://vladmihalcea.com/spring-read-only-transaction-hibernate-optimization/ 위 글을 봤는데  제가 이해하기로는 위 글에서 얘기하는 Entity loaded state 가 말씀하신 스냅샷이고 강의와 동일하게 'queryHint-readOnly를 통해 생성을 막을 수 있다.' 라고 하면서 작성자 본인이 기존에 Transactional-readOnly를 사용했을 때 Entity loaded state(스냅샷) 생성이 막히지 않아 git pull 요청을 해서 spring 5.1에서 적용됐다는 것 같은데요. 제가 이해한게 맞는지 그렇다면 @Transaction(readOnly=true)를  @QueryHint-readOnly속성과 동일한 기능으로 보고 대체하여 사용할 수 있는지 궁금합니다. 감사합니다.

안녕하세요 이번강의도 정말 잘듣고 있습니다. 다만 궁금한 점이 있다면..스프링 JpaRepository를 쓰면 jpa에 종속적인 repository가 만들어지지 않을까요? 원래 repository 패턴을 장점중 하나가 (캐쉬,api,nosql)등 구체적인  데이터 소스에 대한 의존성을 줄이기 위함이라 알고 있는데.. 실무에서는 사실상 적용하기는 개발공수에 비해 얻는 이점이 크지 않는건가요? 실무에서 그럼보통 nosql로 변경되거나 api로 변경되면(거의 없겠지만) 거의 대부분을 다시 작업하나요? 그리고 혹시 jpql사용시 join 과 fetch join의 차이점은 select 할때 받아오는 컬럼에만 차이가 있는건가요?

안녕하세요? spring 강의 잘 듣고 있습니다. 미니프로젝트 게시판에 다운로드 기능을 추가하고 싶은데 여타 다른 블로그 등을 찾아봐도 너무 어렵고 에러만 나네요 ㅠ 미니게시판에 어울리는 간단한 다운로드 소스 부탁드려도 될까요?

위와같이 Order와 Product Entity가 N:M매핑일 때 1.Order에 대해서 락을 걸고싶은데 이럴경우 OrderItem에 관해서도 락을 걸어주는게 맞는지 궁금합니다 ㅠㅠ OrderItem까지 락을 걸어버리면 컬렉션에 값이 추가될때마다 업데이트 쿼리가 계속 늘어나가지고 성능적으로 문제가 생길거같아서.. 2.애그리거트 단위로 락을 걸어주는게 좋은건가요 ??

선생님 안녕하세요. 수업내용과 무관하지만, 한 가지만 더 여쭤보겠습니다..! 실무에서 커넥션 풀의 개수는 어떤 근거로 결정하나요?? 커넥션 풀을 많이 만들면 어떤 단점이 있는지도 알려주시면 감사하겠습니다..!

선생님 안녕하세요. OSIV 수업을 듣다가 궁금한 점이 생겼습니다. @Transactional이 선언되어있는 메서드 내에서 @Transactional이 붙어있는 메서드를 호출하면 영속성 컨텍스트는 공유 되나요? 아니면 두 개의 영속성 컨텍스트가 생성되나요?

public static OrderItem createOrderItem(...){ // ... } 1. 제목과 동일합니다.  저 같은 경우엔 @Builder를 사용하긴 하는데 빌더패턴보다 더 선호되는 방식인가요? 2. 또한 생성자명을 따로 정하는 이유가 있을까요? 뭔가 의도는 알 거 같기도 한데, 제 추측 말고 정확한 이유가 궁금합니다.

강의 소스 코드 일부를 발췌했습니다. @GetMapping("/api/v2/members") public Result membersV2() { List<Member> findMembers = memberService.findMembers(); //엔티티 -> DTO 변환 List<MemberDto> collect = findMembers.stream() .map(m -> new MemberDto(m.getName())) .collect(Collectors.toList()); return new Result(collect); } @Data @AllArgsConstructor class Result<T> { private T data; } -질문- DTO를 Result<T>로 만들었을 때, - public Result<MemberDto> membersV2() - public Result membersV2() 둘 중에 어떻게 작성하는게 더 좋은지 알 수 있을까요? 항상 타입을 명시하는 Result<MemberDto> 방식으로 사용해왔는데, 선생님 코드에는 뭐든지 이유가 있을 것 같아 이렇게 여쭤봅니다!

안녕하세요? 좋은 강의 감사합니다. 예제 코드를 따라 하던 중 내부 클래스 static class InitService 의 dbInit2() 메소드를 private 으로 바꿔보았는데 EntityManager 가 null 예외가 발생하더라구요 이유가 궁금하여 질문 드립니다. 감사합니다. @Component @Transactional @RequiredArgsConstructor static class InitService { private final EntityManager em; public void dbInit1() { Member member = createMember("userA", new Address("서울", "1", "1111")); em.persist(member); } private void dbInit2() { // InitDB 클래스의 내부 스태틱 클래스 InitService 안에 선언된 private 메소드 Member member = createMember("userB", new Address("진주", "2", "2222")); em.persist(member); // EntityManager null exception }

상속관계에서 빌더 패턴을 사용하려다 보니 어떻게 짜야 가장 효율적이고 선호되는 방식인지 궁금합니다. 일단 저는 다음과 같이 짰습니다. 혹시 이런 문제와 관련해서 참고할만한 레퍼런스가 있을까요?

안녕하세요 진짜 좋은 강의와 선생님의 답변으로 많이 배우고 있습니다. 강의를 따라 하다보니 몇가지 궁금증이 생겼습니다. 1. controller에서 responseEntity 를 안쓰시던데 딱히 이유가 있을까요? 2.계층끼리의 의존성을 낮쳐주기 위해서 dto를 저는 계층끼리 통신할때 쓴다고 알고있었고 entity 가 business layer인 서비스 계층을 벗어나면 좋지않다고 알고있었습니다. 그래서  service에서 controller 로 넘겨줄때 항상 entity를 dto로 만들어서 넘겨주는 방식으로 사용했습니다. 하지만 선생님은  service 계층에서는  controller에 값을 넘겨주지 않거나 id 정도만 넘겨주고 controller 에서 다시조회 하던지 해서 그값으로 resposne dto를 만들어주는 방식으로 하셨습니다. 제가 기존에 하던 방식은 잘못된건가요?  3.OrderSimpleApiController 같은경우는 orderSerivce를 전혀 사용하지 않았더라구요 대부분의 조회가 바로 OrderRepository에서 가능한 부분이었지만 이렇게 바로 가능하면 서비스 계층을 안통하고 하는방식이 나은건가요? 혹시 언제는 단순 위임이라도 서비스 계층을 통해 repository를 사용하는게 좋고 언제는 바로 조회하는게 좋은지 궁금합니다. 

웹 계층 개발, 상품 수정 강의 수강중 질문드립니다. 1. createItemForm 과 updateItemForm 이 많은 차이가 나지 않는 것 같은데 따로 생성한 이유가 있을 까요? controller 와 매핑되는 화면이 하나인 것이 좋은 설계라던가 그런 이유가 있을 지 궁금합니다. 따로 만들면 나중에 필드의 항목이 추가 되거나 하면 변경해줘야 할 화면이 늘어나는 것 같아서요 2. 상속 관계로 매핑된 item 캐스팅의 대안 item의 경우 서비스에서 조회한 객체를 캐스팅하여 써야하는데 설명 중에 캐스팅하는 것이 좋은 방법이 아니라고 하셨는데요 Book book = (Book) itemService.findOne(itemId); 다른 대안이 어떤 것이 있을까요? 캐스팅이라고 하시니 제너릭이 생각나는데 이것이 대안이 될 수 있을 까요? 강의 잘 보고 있습니다. 감사합니다. :)

안녕하세요 정말 유익한 강의 잘듣고 있고요 항상 친절한 답변에 감사함을 느낍니다.  1.create시 createDto로 서비스로 넘어 온다면 아래에 방법중 어떤게 유지보수와 같은 측면에서 가장 나은 선택인가요? a.  model mapper 나 mapstruct 라이브러리로 매핑한다. b. 서비스 계층에서 엔티티 빌더로 dto 값을 하나하나 세팅한다. c. 엔티티 생성자나 빌더에 dto 를 넘기고 그안에서 값을 세팅한다. 2.update시 updateDto로 서비스로 넘어 온다면 아래에 방법중 어떤게 유지보수와 같은 측면에서 가장 나은 선택인가요? a.강의에서 처럼 dto 값을빼서 전달한다. entity.change(updateDto.getA(),updateDto.getB()) b. 전체 Dto를 넘긴다. entity.change(updateDto) 3. update patch시에는 변경하지 않는값은  updateDto에 널로 들어온다면  모든 값을 하나씩 체크하면서 null 이 아닌것에대한 엔티티를 업데이트 해주는 방식이 최선인가요?   4.만약 엔티티에서 dto 로 변환시에는 보통 어떤 방식으로 실무에서 많이 하나요?

영상에서 UI 계층 (Controller)에서 Member Entity Object를 생성해서 파라미터로 넘겨주어 Service 계층에서 회원가입 처리를 하도록 코딩을 하셨는데,원래 UI계층에서 Entity Object를 생성해서 Service 계층에서는 응용서비스 관련 로직만 짜는게 맞는건가요?아니면 앞 영상에서 말씀하셨던, 너무 "Controller -> service -> Repository 로만 구조를 가져가려면 딱딱하고 불편한 점이 있다,"라는 말씀을 하셨던 부분에 해당해서 다르게 코딩하신 건가요?

안녕하세요. 강사님 Abstract 엔티티 클래스를 리턴 받은 후 상속된 클래스를 어떻게 가져와야 좋은 방법일까요? 예를들어, OrderItem에서 Item을 상속한 Book 클래스를 가져오고 싶을 때Book book = (Book) orderItem.getBook(); 이런 식으로 형변환을 하여 Book에 접근할지 또는, OrderItem과 Item을 연관관계 매핑 시 Item대신 Book엔티티를 매핑을 하여Book book = orderItem.getBook()으로 매핑을 할지 고민입니다. 어떤 방법이 괜찮을지 혹은 더 권장되는 방식이 있을까요? 감사합니다.

안녕하세요 매번 친절한 답변 감사합니다. 정말 정말 도움이 되고 있습니다.  이번에는 이런경우에도 jpa 사용이 효율적인지 또는 가능한지를 묻고 싶어서 질문 드립니다. 프로젝트 구조상 마스터와 서브디비 여러개로 구성되어있을때 디비정보가 딱 정해진게 아니라 특정 리퀘스트마다 마스터 디비 를 조회를 통해 서브디비 정보를 얻어와 (ip는 각각 다르지만 테이블 구조,데이터베이스 이름등은 서브디비 모두 동일하다는 가정하에) 동적으로 서브디비와 커넥션을 맺어 사용해야  하는데 이 상황에서도 jpa를 활용가능 할까요 또는 효율적일 까요? 이런경우에서도 jdbc 커넥션풀이 성능에 도움을 줄 수 있을까요?

안녕하세요 항상 정말 강의 잘듣고 있고 평소에 쓰면서 고민했던 부분을 설명해주시고 그리고 질문으로 답해주셔서 정말 도움이 많이 되고 있습니다. orderService에서 orderRepository,memberRepository,itemRepository 처럼 서비스 계층에서 의존성으로 다른 레파지토리를 가지는게 나은건지 아님 서비스로(orderService,,) 가져가는게 나은건지 고민이 됩니다.혹시 실무에서 보통 서비스와 레파지토리 둘중 선택하는 기준이나 각각의 장단점이 있을까요?

질문에서 처럼 두 도메인의 서비스와 두 도메인의 서비스와 레파지토리 SAVE 메서드의 리턴을 하나는 VOID 하나는 id 로 준 이유가 있을까요?

1) 애그리거트를 나누실때 어떤 기준으로 나누시는지 궁금합니다 !! ex) 아이템,주문, 회원, 결제 이런식으로 도메인을 나누는 기준 더 나아가서 아이템에 대한 리뷰, 결제기록, 서비스쿠폰과 같이 애매한 도메인이 추가된다면 어떤식으로 나누어야할지 너무 헷갈립니다 ㅠㅠ 2) 애그리거트 루트를 참조할때는 객체를 통해 접근하면 각 애그리거트간의 결합도가 상승할거같은데 어떤식으로 처리하시나요 ?? ex) 아이템과 주문이 아예 다른패키지이거나 다른프로젝트 일경우 어떤식으로 해야하나요 ??

안녕하세요. 정말 좋은 강의 항상 잘 듣고 있습니다. Repository save 메서드는 Member 를 반환하기보다는 id를 반환하는 식으로 구성하셨는데 이게 기본편에서 커맨드와 커리를 분리한기위함이라고 하셨던걸로 기억합니다. 이론적으로는 조회와 insert update 등을 분리한다고 는 이해했는데 실제 웹 어플리케이션 개발떄 이로써는 얻는 이점에 대해 좀더 자세히 들을수있을까요? 그리고 실제 실무에서는 어느정도까지 분리해서 보통 사용하나요?