제가 도메인, 서비스, 레포지토리 같은것들을 자바를 공부하며 처음 알게되었는데요 도메인이라고 하면 계속 www 같은 도메인이 떠오르네요 domain: 엔티티객체의 모음 service: 비즈니스로직 repository: 엔티티객체를 활용한 jpa코드사용 이렇게 생각하면 될까요?? 그리고 웹어플리케이션을 만들때 만들기 나름이겠지만, 쿠키나 세션을 사용해서 로그인처리를 하는지 jwt를 사용하시나요?? 대부분의 웹서비스는 jwt필요없이 쿠키만으로 충분하다는 어느 유튜버분의 의견도 있던데 어떻게 생각하시는지 궁금합니다!

안녕하세요.올려주신 강의 잘 듣던 중 궁금한 점이 생겨 질문드립니다. @Transactional을 테스트 케이스에서 쓸 경우에는 커밋이 안되고 롤백을 한다고 하셨는데, MemberServiceTest에서 만든 2개의 테스트 중 중복_회원_예외() 메서드 실행 시에는 아래 로그에 INSERT쿼리가 나와서요... 회원가입() 메서드 테스트 시에는 INSERT쿼리가 로그에 찍히지 않는데 중복_회원_예외() 메서드에는 INSERT쿼리가 찍히는 이유가 궁금합니다.

안녕하세요.강의 잘 듣고 있던 도중 궁금한 점이 생겨서 질문드립니다.엔티티 설계시 주의점 21분쯤에 cascade옵션에 대해서 설명해 주셨는데, 왜 Order 엔티티에 있는 필드값에만 이를 적용하고 다른 곳에는 적용하지 않으셨는지 궁금합니다. 또한, 어떤 기준을 통해 cascade 옵션을 적용시켜야 하는지 궁금해서 여쭤봅니다.

처음 회원을 등록하면 회원목록에서 #이 1이 뜹니다. 이후 상품 등록을 하고나서 상품 목록을 조회해보니 #2가 뜹니다. 혹시나해서 회원을 하나 더 만들어보니 #3이 추가가 되었습니다. id값이 부여가 되는 것이 테이블별로 이루어지는 것이 아닌 건가요?

안녕하세요. @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 할때 받아오는 컬럼에만 차이가 있는건가요?

위와같이 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,,) 가져가는게 나은건지 고민이 됩니다.혹시 실무에서 보통 서비스와 레파지토리 둘중 선택하는 기준이나 각각의 장단점이 있을까요?