qwef

SpringDataJPA는 구현체가 아니라 인터페이스를 만든다. 그러면 또 프록시가 구현체를 만들어 준다. SpringDataJPA는 이름으로 쿼리를 자동으로 생성해준다. 예를 들어 findByEmailAndName() 이렇게 하면 select m from Member m where m.email=? and m.name=? 이렇게 email과 name findBy 는 select 이렇게 JPQL을 생성해 줌. 인터페이스에 쿼리작성도 가능하다. 메소드에 @Query("select u from User u where u.emailAddress=?" User findByEmailAddress(String emailAddress); 또, @Query(value="sql문", nativeQurey=true) 하면..

원래 스프링 + JPA 조합으로 오랫동안 사용 해 왔음. 근데 어느 순간 굉장히 많은 종류의 DB가 만들어 졌음. 근데 결국, DB는 다 똑같음. 어딘가에 데이터를 저장하거나, 불러오거나 등등. 그냥 CRUD 이렇게 비슷한데, 개발자가 일일히 Mapper역할을 하며 DB마다 CRUD를 구현 해야 했다. 근데, 이럴 바에 굉장히 넓은 boundary의 추상화를 하여 인터페이스를 만들고 그걸 한번 제공해보자. 그래서, SpringData라는 공통 기술이 있고(뭐 CRUD 이런 DB마다 교집합인 공통기술일거임.) 각각의 DB마다 특징이 있는데, 그것을 SpringDataJPA, SpringDataMongo 등 그 DB의 특징에 맞춰 추가로 제공. 스프링데이터는 - CRUD + 쿼리에 대한 것도 제공 - 다른 ..

앞서 JPA는 EntityManager를 통해 사용한다고 했다. EntityManager는 순수 JPA기술이다. 스프링과는 관계가 없다. 따라서, 예외도 JPA관련 예외를 발생시킨다. (아닌 것도 있긴 하다.) PersistenceException 및 하위 그럼 또 예외를 JPA라는 특정 기술에 의존하게 될 수도 있다. 그렇다면 어떻게 스프링 예외(DataAccessException)으로 변화할까? 바로 @Repository이다. 우리가 Spring MVC에서 @Controller, @Service, @Repository 이렇게 있는데, 일단 기본적으로 컴포넌트 스캔의 대상이 되고, (컴포넌트 스캔의 범위 내라면. 스캔범위를 설정 안해놓으면 main이었나 java였었나.. 여튼 되게 상위부터 스캔했음) ..

아무래도 가장 중요한 부분은 객체와 테이블을 매핑하는 거다. JPA가 제공하는 다양한 애노테이션을 사용하여 매핑하면 된다. @Data @Entity //@Table(name="item") public class Item { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name="item_name", length = 10) private String itemName; private Integer price; private Integer quantity; public Item() { } public Item(String itemName, Integer price, Integer quantity) { this...

JPA란 Java Persistence API 직역은 자바 영속성 API 라는데... DB가 영속성이라서 그런건가. JPA의 기본 컨셉은 자바 컬렉션 컬렉션에 add하거나 remove 하는 것 처럼. 자바 진영의 ORM 기술 표준임. 즉, 인터페이스 ORM은 Object Relational Mapping 객체 관계형데이터 맵핑 객체는 겍체대로 설계하고 DB는 DB대로 설계 하는데 ORM이 중간에서 매핑해 줌. 대부분 대중적인 언어는 ORM 기술이 존재함. ORM은 RDB와 객체를 이어주는 기술임. RDB도 잘 알아야 함. ORM 에러의 많은 부분이 DB에서 일어날 거임. 결국 얘도 JDBC를 쓰는 거긴 함. 일종의 뭐 우리가 리스트 쓰듯이 (list.add()) 하듯이 하면 그걸 쿼리문으로 바꿔서 JDB..

지금 시대는 객체를 관계형 DB에 관리 관계형 DB는 sql만 알아들으므로 SQL 의존적인 개발을 피하기 어려움 개발자가 SQL 매퍼 역할을 하는 중 관계형 DB는 상속관계도 없음. 비슷한 게 있긴 하지만 (Super타입, sub타입) 복잡함. 보통 클래스 자체를 DB에 맞춰 정의함. 도메인 말하는 듯. 그리고 만약 예를 들어 Member 객체가 Order 객체를 가지고 있다고 생각해 보셈. 클래스로써는 상상이 가지만 DB에서는 어떻게 구현할거임? 이럴 경우 보통 Order의 Id를 가지고 있다가 따로 Order 테이블에서 JOIN 시킴. JOIN : sql 명령어 중 하나. 둘 이상의 테이블을 연결해 데이터를 검색하는 방법. 적어도 하나의 컬럼을 공유하고 있어야 하며, 이 컬럼을 PK또는 FK값으로 사..

JPA는 ORM DB접근 기술 ORM은 Object Reletional Mapping 직역은 오브젝트 관계 매핑인데 sql문을 직접 작성하지 않고 마치 리스트에 객체를 넣는, 그런 느낌이다. 알아서 sql문으로 바꿔서 보낸다.

마이바티스 사용하는 최고의 이유는 if, chose, trim, foreach 등의 동적쿼리 기능 때문 대충 이런 식임. choose는 뭔가 switch와 비슷한데, 근데 특정 값이 case가 아니라 조건문임 참일 시 넣을 내용 참일 시 넣을 내용 위의 조건이 모두 만족하지 않을 시 이걸로 넣음. and ~~~~ and ~~~~ and ~~~~ 만약 저기 안에 하나도 안 맞으면 where조차 안 붙임. 근데 하나라도 맞으면, where and는 sql문법 오류이므로 and를 지워줌. 첫번째면. 그 다음부터 맞은 것들은 and 붙여줌. 그러니까 뭔가 알아서 똑똑하게 where ~~~~ and ~~~~ and ~~~~ 이런 형식을 맞춰준다는 거임. ~~~~ 만약 접두사(prefix)에 and나 or가 있으면..

@Configuration @RequiredArgsConstructor public class MyBatisConfig { private final ItemMapper itemMapper; @Bean public ItemService itemService(){ return new ItemServiceV1(itemRepository()); } @Bean public ItemRepository itemRepository(){ return new MyBatisItemRepository(itemMapper); } } ItemMapper가 @Mapper 이거 붙여서 xml이랑 연동되서 뭔가 구현체로 하나 만들어 진 후 빈으로 등록된다. 그래서 주입받을 수 있다. 근데 인텔리제이 문제인지 빨간 줄 뜨기는 하는데, ..

@Mapper public interface ItemMapper { void save(Item item); void update(@Param("id") Long id, @Param("updateParam") ItemUpdateDto updateParam); Optional findById(Long id); List findAll(ItemSearchCond itemSearch); } 먼저 인터페이스를 만듦. 이건 마이바티스 매핑 XML을 호출해주는 매퍼 인터페이스. @Mapper를 꼭 붙여야 인식됨. @Param은 파라미터 하나일 경우에는 안넣어도 되는데, 2개 들어갈 때는 넣어줘야 함. 아마 하나면 알아서 인식해서 되는 듯 함. 그러니까, 따져보면 다 매개변수들이 @Param 붙어있어야 하는데 하나라서 ..