김영한 개발자님 좋은 강의 감사드립니다. 유익한 강의를 따라 스프링 데이터 Jpa를 공부하니 호기심에 이것저것 궁금한게 생기네요. 초보 개발자인 저는 JpaRepository<T, ID>를 활용하면서 설계패턴에 대한 고민을 시작했습니다. 설계패턴을 이론으로 배울때는 별 생각없었는데, 코딩하면서 적용해보니깐 설계하기 애매한게 많더군요. 굉장히 흥미롭고, 그래서 선배 개발자님의 경험이 듣고 싶습니다. 1. JpaRepository는 T에 들어가는 하나의 테이블을 위해서 공통 인터페이스들을 제공해주고 있잖아요. 그렇다면 여러개의 테이블을 위해서는 일일이 JpaRepository를 따로 만들어줘야 할텐데요. 강의에서는 주로 하나의 테이블만을 이용해서 쿼리를 날렸기에, 하나의 JpaRepository로 충분했는데요. 테이블이 한두개면 모르겠는데 테이블 숫자가 많아지면 그에 맞춰 repository 숫자도 계속 늘려줘야 하는건가요? 가령 수백개의 테이블이 있을 경우에도 일일이 repository를 따로 만들어주는 건가요? 2. 테이블당 하나씩 repository를 만든다면, join 쿼리처럼 여러 테이블을 동시에 참조하는 쿼리는 어떤 테이블을 위한 repository에 작성해야할지 모르겠습니다. 예를들어 : '주문자'와 '상품'을 n:n 관계로 잇는 '주문' 테이블을 조회한다고 가정해볼경우. 제가 주문한 상품에 대한 상세정보를 가져오려고 쿼리를 짜면 다음과 같을 것입니다. select (상품명, 상품가격, 유통기한) from '주문' join '상품' on '주문'.상품id = '상품'.id where '주문'.사용자id = 'qwer1234' 그렇다면 이 쿼리를 '주문자repository'에서 작성해야할지, '상품repository'에서 작성해야할지, '주문repository'에서 작성해야할지 모르겠습니다. 테이블 단위로 repository를 만든다면, 여러 테이블을 넘나들며 query를 날리는 비즈니스 로직이 있을경우, 어떤 테이블을 위한 repository에서 그 쿼리를 작성해줘야 할까요? join 쿼리만을 위한 repository를 따로 만들어줄까도 생각해봤고, service 측에서 작성해줄까도 생각을 해봤는데요. service 측에서 작성해주는 것은 service랑 repository를 분리하는 것이 퇴색되는 것 같습니다. join을 위한 repository를 따로 만드는 것은 개발하다 구조적인 문제가 생길지 않생길지 몰라서 확신이 안섭니다. 물론 위에 대한 답변들은 프로젝트의 규모나 비즈니스 로직에 따라서 어떻게 분리할지, 통합할지 얘기가 달라지겠지만, 김영한 개발자님은 실무에서 어떻게 균형있게 분리하셨는지 경험을 듣고 싶습니다. 감사합니다.
안녕하세요! // @PostMapping(value = "/items/edit") @PostMapping ( value = " /items/{itemId}/edit " ) public String updateItem ( @ModelAttribute ( "form" ) BookForm form ) { Book book = new Book (); book. setId ( form . getId ()); book. setName ( form . getName ()); 1. @ModelAttribute를 안붙여도 되는데 강사님은 왜 붙이신건지 알고 싶습니다!! 2. url에 itemId가 form으로 넘어오는 상황인데 이때 url에서 itemId를 빼는 것이 더 올바른 건가요? 아니면 강사님 처럼 사용은 하지 않아도 관례상 넣어줘야 하나요?
안녕하세요! 강사님께서 출판하신 JPA책과 같이 보면서 복습하고 있습니다. Jpa 책 73페이지에 보면 hibernate-entitymanager 핵심 라이브러리를 pom.xml에 등록해서 사용하셨는데 현 강의에서는 spring-data-jpa -> hibernate-core만 있고 엔티티매니저는 없는데 버전이 올라가면서 core만 있으면 되는건지 Maven Repository에서도 못찾아 질문 올립니다. 감사합니다.
안녕하세요~ 김영한 강사님. 기본편 부터 쭉 들으며 열정넘치신 강의 덕분에 많은 배움이 있었습니다. 강의 중에 리포지토리 네이밍에 관해 궁금한것이 생겼는데요, 메인 리포지토리 분리할 경우 고려할 사항에 대해 말씀해주셨는데요, 다음과 같이 정리해 보았습니다. * - Command( 명령성 ) / Query( 복잡한쿼리 ) * - CoreBusinessLogic( 핵심비지니스로직 ) / ViewPrivateLogic(View 계층쿼리로직 ) * - LifecycleStepedLogic( 생성주기에 따른 절차적로직 ) 알려주신 QueryRepository 외에 분리되야 할 부분의 리포지토리의 이름들을 어떻게 구분하면될까요? Query : query.XxxQueryRepository Command : command.XxxCommandRepository CoreBussiness : ? LifecycleStepedLogic : ?? 추측해본 결과로는 이런방식인데요, 1. 실무서 이런방식으로 구분하시는지, 2. 강의 내용 외 분리시킬 리포지토리의 패키지와, 이름을 각각 어떤이름으로 사용하시는지 3. 묶어서 사용할 경우, 어떤것들 끼리 묶어서 사용하시는지 간략한 구체적인 사례들이 궁금합니다. 읽어주셔서 감사합니다!
[엔티티 직접 사용 - 외래 키 값] 강좌에서 질문이 있습니다. "select m from Member m where m.team = :team " 에서 앞에서 배운 "경로 표현식"에서 본 경우와 같이 경로 탐색(m.team)을 사용하므로 묵시적으로 m와 t 사이에 조인이 일어날것 같은데 일어나지를 않네요. 그래서 "경로 표현식"에서 한 예제와 어떤 차이가 나는건지 알고 싶습니다. (* 경로 탐색은 select와 where절에서 사용가능) 감사합니다.
강의 정말 잘 듣고 있습니다. 감사드립니다. 영한님의 경우 프로젝트 재실행마다 모든 DB 테이블이 초기화 되는데, 저는 주문 내역만 초기화되고, 이외의 테이블들은 초기화가 되지 않습니다. ( 근데 또 이상한게 아까 설정 한번 건드려봤을 땐 한번 됐었는데 또 안되네요;; ) 어떻게 설정을 바꾸면 모두 초기화가 될까요? 주문 내역 테이블은 초기화가 되는데, delivery 테이블은 초기화가 되지 않아서 PK 중복 에러가 자꾸 나네요ㅠ main의 application.yml test의 application.yml p.s. 영한님 저서 ' 자바 ORM 표준 JPA 프로그래밍' 책은 2015년 출간 되었던데, 이후 개정된 적은 없나요?!
안녕하세요. 선생님 강의 정말 잘 보고있습니다. 궁금한점이 있어서요 Repository 패키지와 Service 패키지가 보통 구분되어있는데 정확하게 쓰임새의 차이점을 모르겠습니다. 그냥 스프링에서 Service 역할을 하는 것이 스프링 부트에서는 Repository가 하는거로 알고있었는데.. 어떤 경우에 Repository에 구현하고, 어떤 경우에 Service에 구현하는지.. Service에 구현하는것은 조금더 비즈니스 적인 내용을 구성한다고 하셔서 혼란이 조금 생겼습니다.
안녕하세요 바이트버디 관련해서 질문드립니다. 바이트버디 코드와 System.out.println(new Moja().pullOut()); 이 코드를 동시에 쓸 수 없다는게,, Masulsa를 실행하면 Masulsa.class, Moja.class로 컴파일되고 그 클래스 파일들이 로딩되고 실행되기 때문에, 그 이후에 바이트버디를 통해서 class 파일을 조작해도 이미 로딩된 클래스 정보 (메소드 영역에 있는) 를 보고 있기 때문에 적용이 안된다는 의미인거죠? 강의는 이전에 다 봤는데,, 혼자 좀 복습하다가 갑자기 좀 혼동이 되서 질문드립니다 ㅎㅎ
안녕하세요 OrderService 테스트 시 회원을 createMember()직접 만들어서 사용했는데 회원가입 기능인 join을 사용하게 되면 해당 테스트에 필요없는 join 기능이 들어가게 되므로 createMember()처럼 하는게 좋은 것 같은데 맞을까요? 즉, 의미없는 의존은 하지 않는게 좋은 테스트 같거든요. 통합테스트 보다 단위테스트가 중요하다고 하신 것도 필요없는 의존성을 제외하기 위함도 있는 것 같구요
JPA에서는 기본키를 무조건 가져야 한다는 전제 조건이 달려있더라고요. 스택 오버 플로에서도 https://en.wikibooks.org/wiki/Java_Persistence/Identity_and_Sequencing#No_Primary_Key 이곳을 참조하라고 알려줍니다. 만약 로그를 쌓는 테이블이 밑의 형식이라면 스프링에서는 어떻게 구현해야 할까요? String Engine; int Tempeture; Date checkTime; 디비쪽 컬럼을 추가 할 수 없다면 어떻게 모델을 설계하면 될지 잘 모르겠습니다. 마지막으로 이런 고민(디비 중심적 모델 설계?)을 현업에서도 많이 하시나요? 너무 부질 없는 고집 부리는거 아닌가 하는 생각이 많이 듭니다.
안녕하세요~ 궁금해서 질문드립니다. 만약에 em.find(xxx.class, id) 또는 em.createQuery("select ...") 와 같이 조회 전용으로만 사용할 꺼라도 트랜잭션(tx.begin ~ tx.commit)안 에서만 해당 코드를 사용해야 하나요? (트랜잭션 코드 없이 그냥 조회해도 데이터는 조회가 되긴하던데...) 왠지 모든 JPA관련 코드는 트랜잭션안에서 실행을 해야 할꺼 같은 생각이 들어서 질문드립니다. 감사합니다.
