안녕하세요querydsl 강의를 보면서 이런 생각이 들더라구요특정 비즈니스 로직을 수행함에 있어서쿼리를 통해서 한번에 해결할 수 도 있을 것이고아니면 관련된 엔티티를 불러와서 도메인 단에서 해결할 수도 있구요.대부분 전자를 트랜잭션 스크립트 모델 패턴 후자를 도메인 모델 패턴이라고 부르더라구요.저는 이전까지 대부분 후자를 선택했습니다.(유지 보수가 더 쉽다고 생각합니다.)이 두개에 대한 선택 기준이 궁금합니다.

제가 도메인 서비스를 사용해서도메인 영역에서 모든 DB와 프레임워크 관련된 의존성,예를 들어 @Transaction 같은 어노테이션도 안 쓰고모두 레파지토리에 위임해서 하고 있습니다.근데 이럴 경우 Repository 명세나 계약을 서비스에 영역에 두면 또 도메인이 서비스를 참조해야되는 경우라일단은 도메인 영역에 내려서 진행 중에 있는데뭐 다른 방법 없을까요?첫번째로는 응용 서비스레이어에 두고도메인 서비스를 사용할 거면 도메인 객체만을 사용해서 로직을 돌리고 반환해서 응용서비스에서 다 처리해라두번째는 규모가 작다는 가정 하에 똑같은 Repository 인터페이스를 도메인, 응용 영역에 두고 쓴다밖에 방법이 안 떠오릅니다. 첫번째는 머리속에서 굴린거라 분명히 제약사항 엄청만을 것 같아서 힘들어보이고

강사님의 강의를 듣기 시작한 학생입니다.제 개인 github에 강의에서 들은 내용을 정리하며 들을라 하는데,코드를 작성하신 것을 올려도 될까요? 

JPA 로드맵의 JPA를 제대로 학습하려면 스프링 로드맵 DB 접근기술에 있는 jdbcTemplate 관련 강의를 꼭 봐야할까요?

어떤식으로 출처를 남기면 좋을까요??

임녕하세여 질문잇습니다쌤이 밀하시길 단방향으로 설계를 하는게 좋다고랫는데 주문 과 주문아이템은 양방향으로 하신이유가잇을까요??

안녕하세요 연관관계 방향대해서 여쭤볼게잇어서 질문합니다상품이랑 리뷰상품이랑 카테고리 방향에 대해서 질문잇습니다Item <- review : 1:n 단방향Item -> itemCategory -> category1:n n:1이 단방향이 맞을까요?? 구현하다가 양방향으로 변경해야할까요 아니면 단방향으오 해결될까요??

강사님의 훌륭한 강의를 듣고 현재 진행하고 있는 프로젝트에 테스트 코드를 작성하려고 합니다.프로젝트 크기는 크지만(개인적인 생각) 아직 테스트 코드는 작성하지 않았고, 해당 프로젝트는 계층형 아키텍처로 이루어져있습니다.개인적으로 테스트 코드는 유효성 검사를 하는 Presentation Layer보다는 Domain Layer와 같이 중요하고 복잡한 로직이 있는 곳에 더 필요하다고 생각합니다. 그래서 테스트 코드를 작성하는 것도 비용이라고 생각해서 우선은 도메인 로직과 관련된 테스트 코드를 작성하고 컨트롤러와 같이 적은 역할을 하는 곳에 테스트 코드를 차례대로 작성하려고 합니다.테스트 코드를 작성한 경험이 없어서 부족한 점이 많은데 이렇게 테스트 코드를 프로젝트에 도입하는게 맞을까요?강사님의 의견이 궁금합니다!그리고 실무에서도 프로덕션 코드에 맞는 테스트 코드를 모두 작성하시는지 아니면 필요하다고 생각하는 곳에만 작성하시는지도 궁금합니다.

하나 여쭤보고 싶은게 있는데, 기존에 NestJS를 사용하다가 Spring으로 전향하게 되어, NestJS로 작성된 토이 프로젝트를 Spring으로 변환하면서 강의 내용을 체득해보려고 합니다!  토이 프로젝트의 규모도 꽤 크고, 기존에 GraphQL로 작성된 쿼리들을 REST API로 변경할 계획인지라 사실상 새로 제작한다에 가까울 것 같습니다. 이걸 어떤 강의까지 들은 뒤 작업할 지 고민이 되는데, 혹시 조언을 주실 수 있을까요?1. DB 2편 2. 스프링 완전 정복 로드맵3. DB 2편까지 듣고, JPA 실무 완전 정복 로드맵까지 4. 스프링 완전 정복 로드맵과 JPA 실무 완전 정복 로드맵까지 현재 DB 2편 듣고 있는 중이며, 이 강의를 듣기 전엔 Spring에 대한 기반 지식이 아예 없었던 상태입니다.조언 감사합니다!

주인을 선정할때 "외래키가 있는 곳을 주인으로 정해라" 라고 설명이 되어있는데 RDB 를 많이 다뤄봤다면 당연한 개념입니다.이런 개념으로 ERD 설계를 많이 하기는 합니다.(정규식, 비정규식 등의 개념은 있지만, 이 부분은 논외로 하구요~)쿼리 작성시 이 부분이 헷갈리면 join 할때마다 고민이 많아지기는 합니다. 양방향이다 보니 아무렇게나 join 하면 되기 때문입니다. 하지만 쿼리 조인은 반드시 주인을 정해놓고 하다보면 틀이 잡히기 시작하고 inner/left/outer join 등의 개념도 아주 명확해지기는 합니다.저는 이 강의를 보고 이 부분이 어렵다, 이해하기 힘들다고 하셨는데, 전혀 헷갈리거나 힘들지 않았습니다.왜냐하면 이미 10년이상 RDB 쿼리 작성시 이런 개념으로 하다보니 그냥 당연하게 받아들여졌습니다.단지, 객체지향(OOP)에서 이 부분을 어떻게 설계하고 문법을 정했는지가 궁금했습니다.저도 EF(Entity Framework) 하다가 JPA를 공부중인데... 거의 같은 개념이고 받아들이기 쉽네요.이 개념이 계속 어렵다면 RDB join 에 대해서 조금 깊이있게 연습해보시면 이해하는데 많은 도움이 될 것 같습니다.

커뮤니티에서 Mybatis 관련 비슷한 오류가 많아 보이길레, 여러분들의 시간을 아껴드리고자 제가 해결한 방법을 공유해드립니다.Mapper bean not found저의 경우 Spring Boot 버전과 MyBatis 버전 불일치 문제여서 Mapper 빈 생성이 정상 작동하지 않았었습니다. (Mapper Spring 연동 모듈이 정상 작동하지 않은 문제??) // build.gradle plugins { id 'org.springframework.boot' version '2.6.5' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java' }스프링 부트 3.0 이상 버전만 썼기 때문에 습관상 당연히 3.0 버전과 호환이 되는 MyBatis 버전 3.0.1 을 설정했지만위와 같이 영한님의 수업 자료로 진행하셨다면 스프링 2.6.5 로 설정되어 있기 때문에// build.gradle dependencies { //MyBatis 추가 implementation 'org.mybatis.spring.boot:mybatis-spring-boot-starter:2.2.0' }이렇게 바꾸시면 되실 겁니다! Invalid boud statement (not found)XML 파일에 오타가 있거나 XML 파일 경로 설정이 이상할 경우 발생하는 오류라 합니다ItemMapper.xml 파일 경로를 잘 따라한 것 같엤는데 경로가 복잡하기도 했고 그래서 pdf 수업 자료 2번째 방법인 resources/mapper/ItemMapper.xml 로 xml 파일을 옮겼고 (기존 껀 부모 디렉토리까지 삭제)// application.properties #MyBatis mybatis.type-aliases-package=hello.itemservice.domain mybatis.configuration.map-underscore-to-camel-case=true logging.level.hello.itemservice.repository.mybatis=trace mybatis.mapper-locations=classpath:mapper/**/*.xml설정 파일에 마지막 줄 (mapper 경로 설정) 을 추가해서 해결했습니다.저와 동일한 문제가 아니신 분들도 계시겠지만 같은 수업 자료에서 출발했기 때문에 비슷하게 해결되지 않을까 싶어서 글 적었습니다! (질문글이 아니지만)

안녕하세요 강사님 !spring boot를 사용해서 프로젝트를 만든 경험은 있지만 주변 실무자들이 제가 구현한 방식이 올드한 편이라는 피드백을 받고 강사님 spring 기본편과 jpa 해당 강의를 수강하고 있는 학생입니다 !저는 보통 냅다(?) 코드를 치면서 전체적인 흐름을 공부한 뒤 이해가 안 가는 부분을 찾아보는 편이라 스프링 강의를 순차적으로 다 듣는 대신 jpa 강의를 먼저 수강 중인데요.해당 강의를 다 수강한 뒤에 jpa를 활용한 spring 프로젝트 강의를 듣고 난 후 해당 강의를 다시 보고 이 다음 jpa활용 2편을 들으려 합니다.spring 로드맵에서 어떤 강의를 듣는게 좋을지 추천해주실 수 있을까요 ?

// 1. queryDsl version 정보 추가 buildscript { ext { queryDslVersion = "5.0.0" } } plugins { id 'org.springframework.boot' version '2.6.3' id 'io.spring.dependency-management' version '1.0.11.RELEASE' // 2. querydsl plugins 추가 id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" id 'java' } //... dependencies { // 3. querydsl dependencies 추가 implementation "com.querydsl:querydsl-jpa:${queryDslVersion}" implementation "com.querydsl:querydsl-apt:${queryDslVersion}" //... } test { useJUnitPlatform() } /* * queryDSL 설정 추가 */ // querydsl에서 사용할 경로 설정 def querydslDir = "$buildDir/generated/querydsl" // JPA 사용 여부와 사용할 경로를 설정 querydsl { jpa = true querydslSourcesDir = querydslDir } // build 시 사용할 sourceSet 추가 sourceSets { main.java.srcDir querydslDir } // querydsl 컴파일시 사용할 옵션 설정 compileQuerydsl{ options.annotationProcessorPath = configurations.querydsl } // querydsl 이 compileClassPath 를 상속하도록 설정 configurations { compileOnly { extendsFrom annotationProcessor } querydsl.extendsFrom compileClasspath }다른 분께서도 내용 공유를 해주셨습니다만, 저같은 경우에는 영한님 강의와 똑같은 경로로 Q클래스 생성하면서 진행하고 싶어 방법을 찾아보다가 다음 설정을 찾았습니다.출처 : https://data-make.tistory.com/728 저같은 경우 문제는 다음과 같았습니다.compileQuerydsl 로 Q클래스 생성 후, 테스트 코드를 돌리면 java: Attempt to recreate a file for type study.querydsl.entity.QHello 에러 발생generated 폴더를 삭제 후, 테스트 코드를 돌리면 성공.위 상황에서 테스트 코드를 Run 하기 전에 항상 Q 클래스를 만들려고 시도한다는걸 알게되서 build.gradle 마지막에 기존에 Q 클래스가 있다면 삭제하고 진행하라고 코드를 넣어도 똑같은 현상이 반복됐었습니다. 이 후 검색을 하다가 위의 설정을 알게됐습니다. compileQuerydsl 로 Q 클래스 생성 후, 테스트 코드를 돌려도 잘작동합니다. 만약 영한님하고 같은 화면, 흐름으로 강의를 진행하시고 싶은 분들 있으시면 참고하시면 좋을것 같아요.  다들 화이팅입니다.

20분 30초 쯤에 gradle clean build까지 잘 되고 libs까지 이동했는데 그 후에 snapshot은 없고 snapshot-plain만 생성돼있네요...snapshot이 생성되지 않는 이유가 뭔지 알 수 있을까요..?

안녕하세요 김영한 선생님!선생님 강의 덕분에 스프링 공부 재밌게 하고 있습니다! 다름이아니라 코드 예제에서 테이블을 설계할 때 @GeneratedValue 어노테이션을 사용해서 모든 테이블의 PK를 idx로 잡고 비식별 관계로 연결하는 구조를 짜시던데 이 부분에 질문이 있습니다! 예를 들어 유저 테이블의 아이디 컬럼이 Not Null이고, Unique한 값이라고 할 때 이 컬럼이 유저 테이블의 PK역할을 할 수 있다고 생각하는데, idx 컬럼을 단순히 auto increment 타입으로 설정하게 되면 불필요한 컬럼이 늘어나는게 아닌지 궁금합니다! 테이블에서 Not Null이고, Unique한 컬럼이 있음에도 불구하고 auto increment를 활용한 id를 pk로 잡는것의 장점이 있을까요??

QueryDSL 내부 메소드 중fetchResult() 나 fetchCount()는 만료된 메소드에 대해서는 QueryDSL에서 Blaze-persistence Integration 라이브러리 사용을 권장하는데요,Blaze-persistence도 QueryDSL 처럼 쿼리 빌더 API 로서 개발자에게 유지보수하기 좋은 객체를 제공해주고 있습니다.게다가 최신 업데이트 날짜가 글 작성일 기준(2023.06.21) 일주일 이전이라 여전히 유지보수되고 있어서 최신 스프링버전과 호환성도 어느정도 보장되었다고 볼 수 있습니다.개인적으로 SpringBoot 3.1.0 기준으로 다음과 같이 세팅하니 정상적으로 동작하는 걸 확인했는데요, 혹시 저처럼 deprecated 메소드를 쓰는 것이 신경쓰이시는 분들을 위해 공유드립니다.build.gradledependencies { //Blaze-Persistence implementation 'com.blazebit:blaze-persistence-integration-querydsl-expressions-jakarta:1.6.9' implementation 'com.blazebit:blaze-persistence-integration-hibernate-6.2:1.6.9' implementation 'com.blazebit:blaze-persistence-core-impl-jakarta:1.6.9' } BlazePersistenceConfiguration.java@Configuration public class BlazePersistenceConfiguration { @PersistenceUnit private EntityManagerFactory entityManagerFactory; @Bean @Scope(ConfigurableBeanFactory.SCOPE_SINGLETON) @Lazy(false) public CriteriaBuilderFactory createCriteriaBuilderFactory() { CriteriaBuilderConfiguration config = Criteria.getDefault(); // do some configuration return config.createCriteriaBuilderFactory(entityManagerFactory); } }QuerydslBasicTest.java..... JPAQueryFactory queryFactory; @Autowired CriteriaBuilderFactory cbf; BlazeJPAQueryFactory blazeQueryFactory; @BeforeEach public void testEntity(){ queryFactory = new JPAQueryFactory(em); // 이건 동시성 문제를 고민하지 않아도 됨, 해결됨 blazeQueryFactory = new BlazeJPAQueryFactory(em, cbf); ..... 적용 결과기존 QueryDSL 세팅한 것에 추가로 세팅하시면, 만료된 메소드에 대해 Blaze-persistence 객체로 대체되는데요, 기존 querydsl 클래스를 상속 받는 형태여서 QueryDSL이 제공하는 메소드를 그대로 쓸 수도 있습니다.fetchResults는 fetchPage로 바꿔서 사용할 것을 권장하고 있다는 점 참고하시면 될 것 같습니다.추가로 내부로직이라든지 설명이 더 필요하시다면 Blaze-persistence 릴리즈 노트와 Blaze Persistence Document를 참고하시면 좋을 것 같습니다.이 글에 대해 지적 및 피드백 해주시면 정말 감사하겠습니다.감사합니다. 여담 및 고민 :개인적으로 이 라이브러리의 내부로직을 뜯어보면서 분석하고 검증할 수 있는 역량은 부족한지라 분석 및 검증하는 방법에 대해서 팁이라든지, 아니면 blaze-persistence 사용할 시 주의해야할 점이라든지 조언해주실 수 있으시면 정말 감사드립니다. 강의를 듣던 중에 서브쿼리가 발생하는 부분에서는 정상동작하지 않는 것을 발견했습니다.@Test public void findUserDto(){ QMember memberSub = new QMember("memberSub"); List<UserDto> memberDtoList = queryFactory //이건 blazeQueryFactory가 정상 동작하지 않음 .select(Projections.fields(UserDto.class, //생성자 필드 순서에 맞게 변수를 만들어야 한다. member.username.as("name"), // member.age 대신 서브쿼리로 다 최대 나이로 찍고 싶어 ExpressionUtils.as( JPAExpressions .select(memberSub.age.max()) .from(memberSub), "age") )) .from(member) .fetch(); for (UserDto userDto : memberDtoList) { System.out.println("userDto = " + userDto); } }  QueryDSL 쿼리 /* select member1.username as name, (select max(memberSub.age) from Member memberSub) as age from Member member1 */ select m1_0.username, (select max(m2_0.age) from member m2_0) from member m1_0 blaze-persistence 쿼리 /* SELECT member1.username AS name, member1.age AS generatedSubquery_1 FROM Member member1 */ select m1_0.username, m1_0.age from member m1_0 blaze-persistence generatedSubquery라 하여, 서브쿼리를 하나의 alias로 처리를 해버렸는데, 후행으로 이 generatedSubquery 에 대한 정의가 따라오질 않습니다...왜 이런 차이가 나오는지는 모르겠지만 blaze-persistence 활용할 때는 유의해야할 것 같습니다.

안녕하세요. 4강에서 처음 프로젝트 열 때, Gradle 2.7.1로 다운그레이드 하였습니다.원래는 Gradle 3 이상의 버전으로 설정되어 있어서 에러가 났었는데,자바 17이상일 때, Gradle 3 이 사용가능한 모양이더군요.해서 Gradle 2.7.1로 다운그레이드해서 급한 문제는 해결했는데..이대로 진행해도 문제가 되지 않을까요??

강의에서는 controller 만 Mock를 사용했는데 service쪽도 테스트할떄도 Mock으로 테스트를 진행자주 하나요?  2. 이건 개인적인 취향일수도 있는데 dto를 생성할때 재사용성이 없는 class에 내부 클래스 즉 static class를 만들어서 여러개의 class를 만들어서 사용하는 방법도 하시던데 어떤걸 선호 하시나요?

 만약 소스를 업데이트하고 커밋하면 리눅스 EC2서버에서는 빌드를 다시해야하는건지 아니면 다시 깃클론을 해야하는건지 궁금합니다!

최근에 새로운 프로젝트 진행하면서 Spring Boot 3 버전을 사용하게 됐는데해당 프로젝트의 Gradle 설정을 구성하면서 다른 분들의 예제를 보면서 작성한 내용을 공유 드립니다. 아래의 내용은 VSCode에서 진행했습니다. 다른 IDE에서는 테스트해보지 않아 다르게 동작할 수도 있는 점 양해 부탁드립니다. 먼저 Gradle 설정은 다음과 같습니다.plugins { id "java" id "org.springframework.boot" version "3.0.6" id "io.spring.dependency-management" version "1.1.0" //querydsl 플러그인 추가하지 않음 } ... configurations { ... querydsl.extendsFrom compileClasspath //해당 부분은 그대로 유지 ... } repositories { mavenCentral() } dependencies { ... implementation "com.querydsl:querydsl-jpa:5.0.0:jakarta" annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta" annotationProcessor "jakarta.annotation:jakarta.annotation-api" annotationProcessor "jakarta.persistence:jakarta.persistence-api" implementation "com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.0" ... } ...현재 예제에서는 Querydsl의 Gradle 플러그인인 id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"를 사용하지 않습니다. 이전 버전에도 있었는지는 정확하게 모르겠지만 Spring Boot 3로 업데이트 되면서 jakarta 패키지를 사용하기 때문에 해당 패키지에 맞는 annotationProcessor를 추가하여 Gradle의 Querydsl 태스크를 대체합니다.(대표적으로 compileQuerydsl) 그리고 configurations 부분의 querydsl.extendsFrom compileClasspath 구문은 그대로 유지합니다. dependencies 부분에서는 Querydsl 관련 패키지 뒤에 :jakarta를 추가로 입력하고 2 개의 annotationProcessor을 추가해줬습니다. Spring Boot 3 초기에 지원되지 않았던 P6Spy의 경우 2월 10일에 1.9.0 버전으로 업데이트 되어 정상적으로 지원합니다. 그리고 기존에 김영한 님이 가이드 하셨던 코드인//querydsl 추가 시작 def querydslDir = "$buildDir/generated/querydsl" querydsl { jpa = true querydslSourcesDir = querydslDir } sourceSets { main.java.srcDir querydslDir } compileQuerydsl { options.annotationProcessorPath = configurations.querydsl } //querydsl 추가 끝위 코드는 따로 작성하지 않습니다. Querydsl Gradle 플러그인을 통해 Qclass를 생성하는 compileQuerydsl 태스크를 별도로 실행할 필요 없이 프로젝트 빌드 진행 시 annotationProcessor에 의해 Qclass가 자동으로 생성됩니다.(여기서 프로젝트 빌드란 Gradle build 태스크가 아닌 Java workspace 빌드를 뜻함.)아래의 이미지와 같이 @Entity 파일이 수정될 때 수정한 내용이 즉시 Qclass에 반영되는 것을 확인할 수 있습니다.(좌측 Entity class, 우측 Qclass) 위 설정을 통해 생성되는 Qclass의 위치는 /bin/generated-sources/annotations/{프로젝트 패키지}/{Entity 클래스 패키지}입니다.(예제 프로젝트에서 Qclass의 위치, gitignore 처리되어 있어 회색으로 표시 됨) 만약 annotationProcessor를 추가하고 Querydsl 설정을 같이 추가했다면 Qclass가 중복된다는 오류가 발생하여 프로젝트 빌드가 진행되지 않으니 주의 바랍니다. 해당 소스는 다음 링크에서 확인해보실 수 있습니다.404-nut-pound/spring-jpa-querydsl-template (github.com) 그리고 별도로 MongoDB+Querydsl 설정도 공유해 드립니다.404-nut-pound/spring-mongodb-querydsl-template (github.com)MongoDB는 Gradle 패키지 설정 시 약간 달라지고 @Entity 어노테이션은 동일하게 사용합니다.그리고 Querydsl MongoDB 패키지는 JPAQueryFactory를 지원하지 않고 Morphia 패키지를 사용해서 MorphiaQuery라는 객체를 사용하는데공식 가이드를 봐도 해당 객체를 초기화하는 방법을 알 수 없어서 Repository 인터페이스에 QuerydslPredicateExecutor를 상속하여 사용하는 식으로 구성했습니다.