[질문 템플릿] 1. 강의 내용과 관련된 질문인가요?예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요, 강의 수강 중 질문이 생겨 여쭤봅니다. api를 개발하는 과정에서 DTO를 사용하고, 혹여나 그렇지 않을 경우 @JsonIgnore을 사용하는 것을 이해했습니다. 만약 스프링부트 1 강의처럼 뷰템플릿으로 개발할 때에는 컨트롤러 리턴 타입이 객체가 아니라 String이기 때문에 DTO가 필요없을까요 ? (굳이 필요하다면 form 객체..?) 마찬가지로 뷰 템플릿에서는 무한 참조 상황에서 @JsonIgnore을 사용하는 것이 아니라 양방향 편의 메서드로 무한 참조를 방지하면 해결이 되는지 궁금합니다!
안녕하세요 토비님 어플리케이션 계층의 port는 도메인과 외부의 연결을 위해 필요 하다고 알고 있는데 jpa나 마이바티스 같은 기술 또한 도메인 외부의 내용이기에 인프라 계층으로 들어간다고 알고 있습니다 그런데 의존성 역전을 위한 레파지토리 인터페이스를 어플리케이션 계층에 만들면 어플리케이션 서비스에서 도메인에 관련된 내용을 너무 깊게 관여하는 것 같아서 질문 드립니다 어플리케이션과 도메인의 경계를 어디까지로 보는게 좋을까요
질문있습니다! Controller에서 데이터를 클라이언트로부터 요청 받을 때 @RequestBody, @RequestParam, @PathVariable, Dto를 활용하는데, 어떤 경우로부터 클라이언트에게 데이터를 요청받았을 때 어떤 방식을 사용하는게 맞는지를 알고 싶습니다!
안녕하세요 토비님 회원 애플리케이션 서비스 테스트 (2) -25:19 에 대해 질문 드립니다. record 에 @Transactional을 사용하면 실행에는 문제가 없으나 인텔리제이에서 Classes annotated with '@Transactional' could be implicitly subclassed and must not be final 이와같은 경고 메세지를 주는데 무시하고 지나가도 되는건지요?
토비님 안녕하세요. 39. 문서와 코드 다듬기 강의의 updateInfo 테스트 부분 질문이 있습니다. 강의 28:30 부근에서 updateInfoFail() 에 코멘트를 달게 되는데 성공케이스에 대한 코드는 updateInfo() 부분으로 옮기는 것도 좋아보이는데 토비님 생각이 궁금합니다 . updateInfoFail() 의 마지막에 member 가 member2 의 프로필 주소와 중복되는 테스트가 있으므로, member2 의 프로필 주소를 설정해주는 코드가 필요하지만, 하나만 있어도 괜찮지 않을까 생각합니다. 그래서 나머지 성공에 대한 코드는 updateInfo() 메소드로 옮겨 "상세 정보 수정이 가능한 경우"들을 나열하는게 좋다고 생각했습니다. 똑같은 준비작업이 반복되다보니 한 번 세팅해놓고 여러 케이스를 다 검증해보는 것이 낫다고 하셨는데, 현재 테스트 클래스 메소드가 성공/실패로 나뉘어져있어 성공하는 부분은 다른 메소드로 이동하는게 좋아보인다 생각했습니다. 아래 코드에서 성공 케이스와 실패 케이스로 나누어보았습니다. 코드 updateInfo() @Test void updateInfo() { Member member = registerMember(); Long memberId = member.getId(); memberRegister.activate(memberId); entityManager.flush(); entityManager.clear(); var updateRequest = createMemberInfoUpdateRequest(); member = memberRegister.updateInfo(memberId, updateRequest); assertThat(member.getDetail().getProfile().address()).isEqualTo(updateRequest.profileAddress()); // 기존 프로필 주소로 계속 변경 요청 가능 memberRegister.updateInfo(memberId, updateRequest); // 다른 프로필 주소로 변경 가능 memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest("omg123")); // 프로필 주소 제거 가능 memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest("")); } updateInfoFail() @Test void updateInfoFail() { Member member = registerMember(); Long memberId = member.getId(); memberRegister.activate(memberId); member = memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest()); Member anotherMember = registerMember("another@email.com"); Long anotherMemberId = anotherMember.getId(); memberRegister.activate(anotherMemberId); entityManager.flush(); entityManager.clear(); // anotherMember가 member와 프로필 주소 중복 MemberInfoUpdateRequest duplicateProfileUpdateRequest = createMemberInfoUpdateRequest(member.getDetail().getProfile().address()); assertThatThrownBy(() -> { memberRegister.updateInfo(anotherMemberId, duplicateProfileUpdateRequest); }).isInstanceOf(DuplicateProfileException.class); // member와 중복되지 않는 프로필 주소로는 변경 가능 MemberInfoUpdateRequest updateRequest = createMemberInfoUpdateRequest("profile123"); memberRegister.updateInfo(anotherMemberId, updateRequest); // member가 anotherMember와 프로필 주소 중복 assertThatThrownBy(() -> { memberRegister.updateInfo(memberId, updateRequest); }).isInstanceOf(DuplicateProfileException.class); } 좋은 강의 해주셔서 감사드립니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 실전! Querydsl 강의 pdf 파일 ( 5. 실무 활용 - 순수 JPA와 Querydsl ) 동적 쿼리와 성능 최적화 조회 - Builder 사용 부분에서 아래 사진과 같이 s가 누락되었습니다.
안녕하세요. 강의 14분쯤에 말씀해 주신 dirty cheking에 대해서 질문드립니다. order.cancel(); 호출하면, Order의 status 변경되고, 이는 dirty cheking으로 인해 Order에 대해서 update 쿼리가 발생하고, orderitem.cancel()호출하면, Item의 stockQuantity가 변경되고, 이는 dirty checking으로 인해 Item에 대해서 update쿼리가 발생한다. 기본편 및 강의 내용에 대해서 생각해보다가 이렇게 생각했는데 이렇게 이해하는게 맞을까요?
링크 위 링크 속 질문에서 영한쌤이 아래와 같은 답변을 해줬습니다 "서버가 한대만 있고, 자바(JVM)로 웹 애플리케이션을 단 하나만 구동하는 상황이면 자바 만으로 동시성 제어를 할 수 있습니다." MVC 1편 강의에서 배운 내용으로는 클라이언트 요청이 들어오면 was 내에 미리 만들어진 쓰레드들이 각 요청을 받고 서블릿 코드를 실행한다고 이해하고 있습니다 그렇다면 서버가 한 대여도 쓰레드는 이미 여러개가 만들어져 있으므로 동시에 여러 요청 처리가 가능하기에 자바만으로 동시성 제어가 안 되는거 아닌가요? 잘못 이해한 부분이 있다면 지적부탁드립니다
안녕하세요. Order와 OrderItem엔티티에 있는 CASCADE에 대해 기본편을 복습해도 헷갈린 부분이 있어서 질문드립니다. em.persist(order)를 하면 CascadeType.ALL때문에 Delivery랑 OrderItem도 insert가 되는거 같은데, @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "order_id") private Order order; OrderItem에 있는 이 부분에 CASCADE를 적어준게 아니라 @OneToMany(mappedBy = "order", cascade = CascadeType.ALL) private List<OrderItem> orderItems = new ArrayList<>(); 왜 Order에 있는 여기에다가 CASCADE를 적어준것일까요? 어디에다 두어도 상관없을거 같은데, 특별한 규칙이 있는것인지 질문드립니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요 ~ 강의 복습 중 궁금한게 생겨 여쭤봅니다 ! 도메인 설계 시 지금처럼 회원 - 주문 - 상품을 메인 도메인으로 잡지 않고 회원이 회원가입, 주문 기능을 수행하는 주체이기에 회원 속에 Embedded로 주문 클래스를 값타입으로 잡아 회원 속에 넣고 회원 - 상품을 메인 도메인으로 잡을 수도 있겠다는 생각이 들었는데, 스프링부트 1 예제처럼 주문과 배송 클래스를 하나의 엔티티로 규정한 이유는 주문과 배송에서 식별자 pk 값이 필요하다고 생각해서 한 것일까요 ? 회원 도메인이 회원 가입 관련 역할만 담당하는 도메인이라서 책임 분리를 위해 주문과 배송 클래스를 다른 엔티티로 규정했는지 라는 의문도 들었는데, 엔티티로 잡아야하는 기준에 대해 여쭤보고 싶어 질문 남깁니다 !
@EventListener(ApplicationReadyEvent.class) 와 같은 기능을 사용하기 위해 @Component public class DataInitializer implements ApplicationListener<ApplicationReadyEvent> 를 사용하여 프로젝트를 운영하고 있습니다. 혹시 잘못된 것인지 궁금합니다.
안녕하세요. 토비님, 강의 잘 듣고 있습니다. 🙂 오늘은 강의 내용에서 좀 굉장히 의외인 부분을 발견해서 질문드립니다. 강의 #41. MemberApi와 웹 단위 테스트 에서 MemberRegisterRequest 가 domain 레이어에서 정의했던 클래스임에도, @RequestBody 파라미터 그대로 쓰셨는데, 이 부분이 많이 의외고 우려가 되었습니다. 저렇게 하면 MemberRegisterRequest 클래스의 코드 변경이 api 스펙 변경을 의미하는지가 코드리뷰 상에서 쉽게 보이지 않고 숨겨질 수 있다는 염려가 됩니다. 실제로 MemberRegisterRequest 에 필드를 추가해서 PR 을 올리면 코드리뷰어가 봤을 때 domain 레이어의 특정 모델에 필드가 추가됐을 뿐인 작은 변경으로 보일 것입니다. 그래서 그것이 어느어느 API 의 스펙에 영향을 주는지 알기가 너무 어려울 것 같습니다. 그래서 저는 API 의 스펙이 되는 Request, Response DTO 의 경우 반드시 클래스를 별도로 분리해야한다고 생각합니다. API 스펙은 server 마음대로 변경할 수 있는 서버만의 코드가 아니라 client 와의 계약 문서라고 보기 때문입니다. 그래서 Request/Response 같이 백앤드 엔지니어가 함부로 변경할 수 없는 영역과 맘대로 변경 가능한 영역을 분리해서, 어플리케이션과 도메인 로직의 변화가 API 스펙 변경으로 인한 장애 걱정으로 이어지지 않게 하는 것이 중요하다고 생각합니다. 이게 근데 단순히 클래스 분리만 해둬도 PR 에서 API 스펙이 어떻게 바뀌는지 쉽게 트래킹이 가능해지기 떄문에 이 부분 만큼은 번거롭더라도 실보다 득이 훨씬 많아서 꼭 분리해야한다고 생각해왔습니다. 이 부분에 대해서 어떻게 생각하시는지 궁금합니다.
