qwef

딱 정답이 있다곤 할 수 없음. 상황에 맞춰, 사람에 맞춰 하는 게 좋다고 생각. JdbcTemplate, MyBatis는 SQL을 직접 작성해야 하므로, SQL에 익숙한 집단에게 좋음. JPA, 스프링데이터JPA, Querydsl은 배울 필요가 있지만, 생산성이 높아짐. 예를 들어 거의 7~80% 통계쿼리만 작성해야 하는 프로젝트면 MyBatis도 괜찮음. 근데 보통 애플리케이션은 로직과 약간 일부의 통계 보통 이런 식이긴 하다. 그래서 보통 선생님이 추천하는 방식은, JPA, SpringDataJPA, Querydsl을 기본으로 사용하면서, 해결이 잘 안되는 복잡한 쿼리를 직접 짜는게 나을 경우 JdbcTemplate나 MyBatis 등을 함께 사용. 거의 실무에서 95%정도 JPA,SpringDat..

기존 에서 이 구조로 한번 변화시켜 볼 것이다. Service에서 자동으로 생성되는 SpringDataJPA를 직접 쓰면서, Querydsl이 필요한, 복잡한 동적 쿼리가 필요한 것은 저렇게 우리가 구현해 놓은 리포지토리를 쓴다. 즉, 같은 테이블 이지만 리포지토리를 2종류 쓰는 것이다. 여튼, 스프링데이터JPA는 스프링데이터JPA상속받은 인터페이스를 만들어 놓으면, 자동으로 빈에 등록이 되고, Querydsl쓰는 리포지토리는 만들어서, 그 두개를 서비스에서 적절히 사용하면 된다. @Entity //@Table(name="item") public class Item { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Co..

우리가 과거 SpringDataJPA를 썼을 때의 구조를 보자. 뭔가 우리가 의도했던 repository가 SpringDataJpaRepository와 어댑터 역할을 하는 꼴이 되었다. 그리고, 한눈에 보기에도 좀 복잡해 보인다. 뭐 이렇게 보면 낫긴하다. 여튼간에, 유지보수에도 비용이 든다. 예를 들어 서비스가 추상화에 의존하지 않고 바로 저 SpringDataRepository구현체를 의존한다고 생각해보자. 이게, 우리가 객체지향 SOLID 하면서 추상화에 의존하는게 좋다고 하긴 했지만, 어떤 게 나은지 진짜 곰곰히 생각해 봐야 한다. 만약 위처럼 우리가 의도한 리포지토리가 SpringDataJpaItemRepository의 어댑터 역할을 한다고 했을 때, 유지보수할 때 Service에서는 뭘 의존하..

자, Querydsl을 설정하면 QItem 이라는 클래스가 자동으로 만들어 졌을 것이다. 이제 그냥 그거 쓰면 된다. 이제 쿼리는 JPA, 즉 EntityManager를 통해 간단하게 사용. Querydsl, 조건, 즉 쿼리를 동적으로 변경해야 할 경우 마치 블록 넣듯이 쿼리를 동적으로 변경하여 사용하고 싶을 떄 사용. JdbcTemplate, 위의 저런 것 보다 그냥 쿼리 한번으로 짜는 게 훨씬 깔끔할 경우, 혹은 JPA나 Querydsl로 해결하지 못한 경우 이렇게 3가지 경우로 쓴다. 주는 JPA, Querydsl을 쓰다가, (이 중에서도 주는 JPA이고 동적으로 쿼리를 만들어야 할 경우에 Querydsl) 가끔 쿼리를 직접 작성해야 할 경우 Jdbc템플릿을 쓰는 느낌이다. 일단은, 자동으로 생성된..

build.gradle에 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" 이렇게 넣어 주고 plugins 부분에 id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" 이거 넣어주면 gradle 창에 querydsl 관련 명령어들을 추가 시킨다. 여튼 이게, 뭐 스프링 ..

D : 도메인 S : 특화 L : 언어 쿼리를 특정 도메인에 특화 시킨 제한적인 표현력을 가진 프로그래밍 언어 간결, 단순, 유창 쿼리에 특화된 간결한 언어이며, 다양한 DB의 쿼리를 통합해 지원해 주는 API. 처음 시작은, 쿼리도 사실 DB에 따라 다양함. 근데 이런 쿼리를 추상화해서 통합시켜 보자. 에서 출발. (실제로 여러 DB에서 Querydsl을 쓸 수 있음) 그럼 뭐 인터페이스에, 표준화 시키고 각 DB의 쿼리에 따라 구현해 놨겠지. 쿼리를 자바코드로 쓸 수 있게. 여러 DB의 query를 type-safe하게 쿼리로 만들어 줄 수 있음.(자바코드로 만들어 줄 수 있음. 오류 있으면 뱉으면서.) 잘은 모르겠는데, type safe한 쿼리를 작성하려면 코드가 좀 필요하다고 한다. JPA같은 경..

자, 이제 동적 쿼리 문제를 해결해 줄 기술 Querydsl이다. 만약 sql이 클래스처럼 타입이 있고 자바코드로 작성할 수 있다면? 막 내가 u만 쳐도 알아서 username이 emmet 기능으로 나오고 그런다면? 그리고 타입구분이 되어서 컴파일 오류도 발생시켜 준다면? (이런 걸 type-safe 라고 함) Querydsl은 쿼리를 자바로 type-safe하게 개발할 수 있게 지원해주는 프레임 워크. 주로 JPQL에 사용. sql 문법의 오류를 잡아준다..! sql도 지원하긴 하는데, 그건 복잡해서 잘 안쓰고, 주로 JPQL에서 사용. 예를 들어, DB에서 다음과 같은 조건의 사람들을 가져오라고 할 때. 나이 : 20~40살 성 : 김씨 순서 : 나이 많은 순 3명만. @Entity public cl..

우리가 저번에 public interface SpringDataJpaItemRepository extends JpaRepository { List findByItemNameLike(String itemName); List findByPriceLessThanEqual(Integer price); List findByItemNameLikeAndPriceLessThanEqual(String itemName, Integer price); @Query("select i from Item i where i.itemName like :itemName and i.price

implementation 'org.springframework.boot:spring-boot-starter-data-jpa' 이게 build.gradle에 있으면 된다. public interface SpringDataJpaItemRepository extends JpaRepository { List findByItemNameLike(String itemName); List findByPriceLessThanEqual(Integer price); List findByItemNameLikeAndPriceLessThanEqual(String itemName, Integer price); @Query("select i from Item i where i.itemName like :itemName and i...

스프링DataJPA는 JPA를 편리하게 사용할 수 있도록 도와주는 라이브러리 대표적인 기능은 공통 인터페이스 (CRUD) 쿼리 메서드 기능 : 메서드의 이름을 통해 쿼리를 만들어 준다. 공통 인터페이스 이렇게 공통적인 CRUD와 보통 DB들이 공통적으로 가지고 있는 기술들. 스프링DataJPA의 인터페이스 이거 외에도 공통 기능들 대부분 포함. 뭐 DB의 전체 카운트 등등.. 사용법은 public interface ItemRepository extends JpaRepository{ } 하면서 인터페이스로 상속받으면 된다. 마지막 타입을 이렇게 해 놓으면 스프링DataJPA가 프록시로 구현체를 만들어 스프링 빈에 등록해 준다. 쿼리 메서드 기능. 메서드 이름을 findByUsernameAndAgeGreat..