안녕하세요 강의 잘 듣고 있습니다. 강의를 듣는 도중에 궁금한 점이 있어서 이렇게 질문 드립니다. 컨트롤러의 return타입은 entity를 캡슐화 하기 위해 DTO를 사용하고, 각 Layer 별로 데이터를 주고 받을 때 DTO 또는 Entity를 상황에 맞게 사용하고있습니다. 또한 Repository에서는(Service -> Repository) Entity를 넘겨주어서 사용하도록 하고 있습니다. 이유는 DTO는 Getter,Setter로 가변이지만 Entity는 불변객체이기에 영속 계층에서는 가변 객체를 파라미터로 넘겨준다면 위험하다고 생각해서입니다. 그런데 강의에서는 DTO를 Repository 까지 전달하시는 것을 보고 DTO가 영속 계층까지 가는것에 문제가 없는가 궁금하여 질문드립니다. 추가로 AEntity의 Repository에서 BEntity를 파라미터로 받아도 설계상?으로 괜찮은지도 궁금합니다. class MemberRepository{ //파라미터로 DTO 받기 List<Member> findMember(MemberDto memberDto){ ... } //파라미터로 다른 Entity 받기 Member doSomething(Team team){ ... } }
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요. 김영한님의 강의를 잘 보고 있습니다. 강의를 보던도중, 문득 의문점이 들어서 여쭤보고자 질문을 작성하게 되었습니다. 질문의 테마는 값 타입 컬렉션과 기본키라고 할 수 있겠네요. 기본 지식 테이블은 기본키가 있을수도, 없을수도 있다. 제가 배운대로는, 테이블은 기본키가 존재할 수도 있고 존재하지 않을 수도 있다고 배웠습니다. 그리고 기본키를 두는 이유는 기본키가 겹치지 않도록 해서, 데이터 중복을 막고, 조회 시 효율 증가를 위해서라고 생각했습니다. 김영한님의 강의에서 말하는 값타입은 주소가 다르더라도 안에 있는 값이 모두 같다고 하신걸로 이해했습니다. 그래서 자바 객체가 값타입으로 들어가는 경우에는 equals를 통해서 같은지를 비교한다는 것도요!! 김영한님의 강의 중 예제로 들어주셨던 Member의 favoriteFoods, addressHistory는 값 타입을 데이터베이스 테이블로 변환한 예시로 이해했습니다. 그리고 강의 내용에서 JPA를 이용해서 Table 구조를 생성하는 걸로 이해했습니다. 여기까지가 제가 이해한 내용입니다. 저는 그래서 해당 구조로 데이터베이스를 만들어준다고 인지했고, FAVORITE_FOOD, ADDRESS는 각각 중복값이 들어갈 수없다고 생각했습니다. 문제상황 하지만 테이블의 생성 내용을 보면, 기본키 설정 부분이 빠져 있습니다. 외래키 매핑만 되어 있고 실제로 기본키 부분이 빠져있습니다. 제가 만든, ADDRESS 테이블을 예시로 들면, 이는, FAVORITE_FOOD 도 동일합니다. 정말 중복값이 들어갈 수 없는지 테스트해보았습니다. 테스트를 위한 코드는 다음과 같습니다. Address address = new Address("newCity", "street", "10000"); Member member1 = new Member(); member1.setName("member1"); member1.setHomeAddress(address); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("피자"); member1.getFavoriteFoods().add("족발"); Address oldAddress = new Address("oldCity3", "street", "10000"); member1.getAddressList().add(new Address("oldCity", "street", "10000")); member1.getAddressList().add(new Address("oldCity2", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); em.persist(member1); 결과값은 다음과 같습니다. 값을 보게되면, FAVORITE_FOOD의 경우는 Set 자료구조 사용으로 중복값이 들어갈 수 없는 것이고, ADDRESS의 경우는 중복값이 들어갈 수 있었습니다. 만약 값의 변경이 일어나는 경우에는 어떻게 될까? 하는 고민이 생겨, 중복으로 들어있는 내용의 값을 변경해보았습니다. Address address = new Address("newCity", "street", "10000"); Member member1 = new Member(); member1.setName("member1"); member1.setHomeAddress(address); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("치킨"); member1.getFavoriteFoods().add("피자"); member1.getFavoriteFoods().add("족발"); Address oldAddress = new Address("oldCity3", "street", "10000"); member1.getAddressList().add(new Address("oldCity", "street", "10000")); member1.getAddressList().add(new Address("oldCity2", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); member1.getAddressList().add(new Address("oldCity3", "street", "10000")); em.persist(member1); em.flush(); em.clear(); Member findMember = em.find(Member.class, member1.getId()); System.out.println("================== Start 2 =================="); findMember.getAddressList().remove(oldAddress); findMember.getAddressList().add(new Address("newCity1", "street", "10000")); tx.commit(); 결과값은 다음과 같습니다. 중복값을 한번에 지워준다면, 그래도 결과적으로는 ADDRESS값을 중복이 없는 값객체로 쓸 수 있겠다고 생각했지만, 모두 지우지 않고 중복값을 하나만 지웠습니다. 물론 List의 특성 상 중복 값 한개만 지우는게 당연하지만요. 가설 목표하던 테이블 구조로 실제로 만들어지지 않았다고 생각했습니다. -> 기본키가 없다. 왜냐하면 생성하고자 하는 테이블 구조와 생성된 테이블 구조가 다르기 때문입니다. 음식에서 중복이 생기지 않는 이유는 Set의 특성 때문이지 테이블 때문이 아니라고 생각이 들었습니다. 값 객체의 특성 상 중복을 허용하는 경우는 없다. 좋아하는 음식의 경우 같은 음식이 두번 있을 이유는 없지만, 이전의 주소의 경우는 같은 주소에 두번 이사갈 수 있다. 그렇다면 음식과 다르게 주소의 경우는 중복이 가능하고, 값을 추적할 수 있어야 하므로 Entity로 사용하는게 맞지 않을까요? 이 부분은 김영한님깨서 설명해주신 부분과 일치하지만, 결론까지 도달한게 맞는지 궁금합니다. 두서 없이 길게 적은 것 같은데, 제가 생각한 가설이 맞는지가 궁금합니다. 그리고 나아가 가설까지 도달하는 방식에 문제가 있거나 고칠점이 있다고 피드백도 부탁드립니다. 읽어주셔서 감사합니다.
따라하며 배우는 노드, 리액트 시리즈 - 레딧 사이트 만들기(NextJS)(Pages Router)
안녕하세요 선생님 첫화면엔 커넥션 리퓨즈 뜨고 회원가입 누르면 이러한 오류가 뜹니다 넘어가질 않고 오류가 계속나오는데 왜이런걸까요?.. 무엇이 문제인지 궁금합니다 :4000 으로 계속 찍히는거 보면 cors가 안되는것일까요 강의보고 다 제대로 따라했는데 ㅠㅠ 도와주시면 감사하겠습니다
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 스프링부트 3.0, JDK17 사용중입니다. AOP 코드를 넣지않고, 스프링 빈 클래스가 잘 찍히는지 확인해보다가. 강의 설명과 다르게, AOP 설정을 넣지 않았는데도 프록시객체가 찍힙니다.
Optional 첫번째 강의영상 10분20초쯤 나오는 내용인데요. progress.ifPresent((p) -> { this.progress = p }); 위와 같은 코드가 나오는데, 제가 알기로는 람다식에서는 외부변수를 변경하면 안되는것으로 알고있는데 this.progress는 외부변수인것같은데도 변경이 되는것 같아서요..! 이 경우에는 외부변수를 변경하는게 왜 가능한지 궁금합니다. 또, 변경가능하다면, 이렇게 외부변수를 변경하는 것은 지양해야하는 건가요?!
안녕하세요. [ 프록시와 연관관계 관리 - orphanRemovel ] 내용에서 질문드립니다. orphanRemovel = false, cascade = ALL 로 설정한 상태에서 @OneToMany 로 설정된 컬렉션 내의 값을 제거하면, cascade 옵션에 의해 update 쿼리가 나갈 때 컬렉션에서 제거된 원소가 같이 삭제되어야 하는게 아닌가요? 위 내용이 틀렸다면 cascade 의 delete 쿼리는 부모 엔티티 '자체'가 사라졌을 때만 컬렉션 내의 자식 엔티티들에게 전이되는 걸까요?? 추가로, 고아 객체 제거 기능은 cascade 와 마찬가지로, 연관관계의 주인이 아닌 컬럼에서도 사용이 가능한건지도 궁금합니다! 내용이 잘 이해되질 않아 질문이 다소 두서없는 점 죄송합니다ㅜ
안녕하세요 강의 완강 후 따로 프로젝트를 만들어 보던 중 궁금한 게 생겨서 질문 드립니다. PostMapping으로 등록할 때 CreateRequest라는 별도의 클래스를 만들어 주어서 파라미터로 받았는데 이 CreateRequest안에 List를 받아야 할 경우가 있다면 어떻게 해줘야 하는지 잘 모르겠습니다. Product 클래스 입니다. Module 클래스 입니다. 하나의 Product에 여러 개의 Module이 들어갈 수 있기 때문에 ProductModule 클래스를 만들어줬습니다. 이러한 경우에서 Product를 등록할 때 아래와 같이 넘겨주고 싶으면 CreateProductRequest 에서 List를 어떤식으로 받아줘야 하나요? 아래와 같이 해봤는데 잘 안되는 것 같아서요...
관련 질문에 대한 답변을 읽어봤는데도 이해가 가지 않아서 질문드립니다. 커맨드와 쿼리를 분리해야한다는 CQS를 설명하신 말이었어요. 내부변경이 일어나는것은 커맨드, 명령어라고 부른다 커맨드는 결과값을 그대로 반환하면안된다 내부변경이 일어나지않는 것은 쿼리라고 부른다. 쿼리는 결과값을 반환한다 -> 1. 커맨드에서 결과값을 반환하면 안되는 이유가 뭘까요? update 메서드 안에서도 결국은 update하는것(커맨드)과 findOne(쿼리)하는 코드가 모두 들어가있는거잖아요? 근데 이게 왜 cqs를 지킨 사례인거죠? @Transactinal public vodi update(Long id, String name){ memberService.update(id,name); Member member = memberService.findOne(id); rreturn ~~~; }
강의도중에 설명해주시긴 했는데 그래도 이해가 덜 가서 질문드립니다 membersaveDto만있으면 memberupdatedto를 만들지 않아도돼요 둘다 만들게 되면 코드의 중복이 발생하는것아닌가요? save와 update는 아예다른것이기때문에 중복이 발생해도 상관이 없는걸까요? 아예다른것이라기엔 update에도 있고 save에도 있는 필드에 변화가 생겼을때 둘다 수정을 해주어야해요 그럼 수정해야할 포인트가 늘어나는건데도 updateDto를 생성해주는게 맞는걸까요?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 강의에서는 개발과 테스트 코드가 모두 동일한 h2 DB 기반으로 구현이 되는데 실무에서는 테스트 코드에 대한 DB 연결을 어떤식으로 하게되는지 궁금합니다. 예를 들어 실제 개발은 A 서버의 mysql 을 사용하고 테스트는 로컬의 h2 로 별도로 연결을 하는지, 아니면 동일한 서버(환경)에서 테스트용 테이블들만 별도로 만들어서 하는지, 또는 모든 환경을 동일하게 하고 테스트 코드만 인메모리에서 실행되게 하는지, 실제 개발 시에는 테스트 코드에 대한 서버, DB 구성 방법이 궁금합니다.
안녕하세요! 일대일매핑을 '주 테이블에 외래 키'로 사용했을 때 단점이 값이 없으면 외래 키에 null을 허용하는 것이라고 되어있는데 이 부분 잘 이해가 되지 않아서요ㅜㅜ '대상 테이블에 외래 키' 방식으로 일대일 매핑을 하더라도 결국 대상 테이블 입장에서는 값이 없으면 null이 들어가는 건 마찬가지 아닌가요??
안녕하세요. 로드맵 수강하고 토이 프로젝트 진행 중인데 궁금한 점이 계속 나오네요.. 일반적으로 사용하는 표현 - 비즈니스 - 도메인 계층 구조에서 비즈니스 정책을 검증하는 위치와 관련해서 질문 드립니다. 예를 들어 사용자용 게시글 삭제 API는 현재 요청 사용자가 게시글의 작성자가 맞는지 검사합니다. 이 검증 작업을 서비스 계층에서 처리했습니다. public class PostService { private final PostRepository postRepository; // 게시글 삭제 기능 public void deletePost(Long postId, Long currentMemberId) { // 엔티티 조회 후 게시글 작성자가 현재 요청 사용자( currentMemberId )와 일치하는지 검사 Post post = postRepository.findById(postId); if (!post.getWriter().getId().equals(currentMemberId)) { // 작성자가 아니면 예외 발생 } post.delete(); } } 이 메서드를 사용자 API 컨트롤러에서는 잘 사용했는데, 관리자 API는 게시글 작성자 검증이 필요 없다 는게 문제였습니다. 사용자 및 관리자용 API 컨트롤러에서 호출하는 것은 결국 '게시글 삭제'라는 동일한 기능이므로 하나의 서비스 클래스에서 제공하는 게 맞다 판단하여 deletePost() 메서드에서 수행하던 유효성 검증 로직을 사용자 API 컨트롤러로 이관했습니다. public class PostController { private final PostService postService; // 실제 코드는 아니며 설명용 코드입니다. // 예를 들어 currentMemberId의 경우 실제론 @AuthenticationPrincipal 등을 통해 얻습니다. @DeleteMapping("/{postId}") public void delete(Long currentMemberId, @PathVariable Long postId) { Post post = postService.findPost(postId); if (!post.getWriter().getId().equals(currentMemberId)) { // 작성자가 아니면 예외 발생 } postService.deletePost(postId); } } 이렇게 구성하니 PostService 를 사용자 API 컨트롤러에서도, 관리자 API 컨트롤러에서도 사용 가능했지만.. 표현 계층에서 비즈니스 정책을 검증하니 구조가 이상한 것 같아서 질문 드립니다. '게시글을 삭제하려는 사용자가 게시글의 작성자인가?' 를 확인하는 작업은 비즈니스 정책에 의한 작업이라 생각합니다. 그러므로 서비스 계층에서 검사하는 게 맞다 생각되는데, 관리자 API에서 사용하기 불편하더라구요. 이런 경우 구조를 어떻게 가져가시나요? PostService 는 비즈니스 로직만 처리하고, PostUserService 같은 래퍼 서비스를 만들어 검증 부분을 처리할까 했는데, 썩.. 맘에 들진 않았습니다. 예시처럼 정책 검증을 컨트롤러에서 수행한다 가정하면, 제 코드의 경우 PostService.findPost() 메서드에 @Transactional(readOnly=true) 를 적용한 상태라 deletePost() 메서드에서 SELECT 쿼리를 또 실행합니다. @Transactional(readOnly=true) 은 정말 필요한 곳에만 선택적으로 적용하시나요? 아니면 읽기 전용 메서드는 별도로 구분하시나요? '서비스는 최대한 비즈니스 로직만 수행하고, 정책 유효성 검증은 다른 위치에서 진행하는 것이 좋다'라는 분들도 있던데, 보통 어떤 식으로 처리하시나요?
