화면에서는 엔티티를 사용하지 않고 DTO를 사용한다. persistence 티어(엔티티) busniess 티어 presentation 티어(DTO) 티어가 다르니 서로 연관이 없고 매핑이 되지 않는다. 엔티티에 create생성자를 지우고 id같은 시퀀스값을 제외, 화면에서 받을 수 있는 것들만 생성자로 만들어서 @Builder 어노테이션을 붙여준다. => 빌더패턴 안에 있는 내용이 다 전달되어야지만 객체가 만들어진다. Entity : 화면에서 받을 것만 생성자로 제작 후 @Builder 엔티티에서 빌더패턴으로 생성자를 만들면 알아서 static으로 바뀐 다음에, xxx.builder를 쓰는 것임. DTO에서는 화면에서 전달받은 것을 엔티티로 바꿔줘야지 레포지토리에 등록이 됨. 영속성 컨텍스트에 전달이 됨..
엔티티를 수정하거나 건드렸으면 반드시 maven > lifecycle > compile 해주어야 함. 이거를 해줘야 쿼리dsl에서 생기는 Q엔티티들이 생긴다. fetch는 list fetchOne은 해당 타입으로 결과가 하나가 나옴 DTO로 리턴하는 방법 화면에서는 엔티티를 사용하면 안됨. 엔티티는 서비스단까지 사용하는 것임. 서비스의 리턴타입은 dto여야 함. 서비스에서의 리턴타입은 dto 엔티티는 서비스 메소드안에서만 쓰고 결과는 dto로 나와야 함. dto로 화면에 나와야 함. 엔티티가 나가면 오류생김. 엔티티를 기준으로 결과를 조회했을 때 조회한 결과를 바로 DTO에 넣어서 DTO로 리턴을 한다. jpql에서는 직접 소속을 다 알려줘야 함. 위 과정을 queryDsl은 dto에 생성자위에 @Que..
쿼리DSL를 쓰기 위해서는 pom.xml에 추가하기(maven) dependency 추가 com.querydsl querydsl-jpa com.querydsl querydsl-apt plugin 추가(plugins태그 안에) com.mysema.maven apt-maven-plugin 1.1.3 process target/generated-sources/java com.querydsl.apt.jpa.JPAAnnotationProcessor Maven > Lifecycle > compile 해야 함..! 쿼리dsl은 build를 시켜야 사용할 수 있음. 엔티티가 다 인식이 되어서 Q가 붙는다. >> querydsl에서 사용하는 객체 엔티티들을 빌드를 통해서 따로 만들어 놓는다. (target에서 실제 경로..
레포지토리가 만들어주는 메소드가 아닌 쿼리메소드로 쓰기엔 너무 길어지거나 불가능할 땐, 쿼리 어노테이션의 JPQL을 사용함. mybatis는 영속성 컨텍스트 없음. mybatis와 jpa같이 사용 가능. xml에 있는 쿼리를 mapper에서 실행하고 mapper를 사용하면 됨. 끝. mapper interface를 dao에서 사용함. dao가 jpa에서는 repository로 대체가 된다. 커스텀레포지토리 spring data jpa, 순수 jpa랑 같이 써야 할 때 jpa랑 mybatis랑 같이 써야 할 때,.... 우리가 직접 interface를 따로 만들어서 레포지토리에 상속시켜주는 것임.. ** mybatis 설정 config > MyBatisConfig application.properties ..
여기서 양방향이라고 가정하면, Owner.java pet -> owner owner -> pet 단방향2개 >> 연관관계의 주인을 찾아야 한다. select일 때는 상관없으나, insert, update, delete일 경우, 복잡성이 증가 하기 때문 pet안에 있는 owner_id(fk)를 관리하는 객체를 연관관계의 주인이라고 하며, owner객체가 연관관계의 주인이다! pet안에 있는 owner를 통해서만 insert, update, delete 접근할 수 있게 해준다. 반대방향으로 접근하지 못하게 한다. mappedBy = "owner"
pet에서만 owner에 접근 가능 다대일 연관관계 단방향 관계(n:1) pet은 여러마리고 owner 1명 >> @ManyToOne pet을 호출했을 때 거기에 있는 주인도 쓸 수 있다. @JoinColumn(name = "OWNER_ID") name에는 엔티티의 pk 컬럼명을 써줘야 함. 즉시로딩(EAGER) : 미리 다 로딩을 해놓기 때문에 필요한지 필요하지 않은지 모르니까 일단 다 조인해서 가져옴. 성능이 안 좋다. 실무에서 사용금지! 지연로딩(LAZY) : 내가 필요할 때 다시 쿼리문이 나가는 것. 로딩을 fetch라는 옵션으로 줄 수 있다. 지연로딩 : 기존의 엔티티를 상속받은 proxy객체가 들어가 있음. proxy에는 id값만 들어가 있고 나머지 컬럼은 null임. 즉시로딩 : 처음에 싹다..
상속과 연관관계는 다르다. 연관관계 : 의존성에 관련됨. RDB는 관계를 맺는 순간 양방향 객체는 양방향은 없음. 무조건 단방향만 있음. >> 자바는 단방향2개로 해결 객체는 참조로 접근(마침표 . 안에 .안에) RDB는 FK로 접근 다양성도 고려해야 함. 1:n n:1 n:n 단방향2개? 양방향1개? > 누가 FK관리하는지가 중요 > 테이블상 안에 FK가 있는 테이블이 FK를 관리 > 연관관계의 주인은 테이블 안에 있는 FK 객체가 주인임. 항상 n 쪽이 FK가 있는 것임. > n쪽의 FK를 연관관계의 주인으로 설정하고 반대편에 있는 객체는 주인에 속해있는 것임. PET이 FK를 관리하고 FK인 OWNER가 연관관계의 주인이다. OWNER테이블은 주인 안에 속해 있는 것이다. //setting > in..
27~36번처럼 직접 넣을 필요가 없음. 22~25번처럼 어노테이션만 쓰면 되는데 spring data jpa이다. 어노테이션을 쓰는 게 auditing이다. @EntityListeners(AuditingEntityListener.class)를 사용해줘야 함. DB에서 insert나 update된게 listener가 감지해서 now를 주입을 해주는 것임. Application에서 @EnableJpaAuditing 을 붙여주어서 spring한테 auditing 허락을 받아야 사용가능하다.
모듈화 방식 : jpa가 봤을 때는 1,2번 차이가 없어야 한다. db에서는 하나의 테이블의 동일한 컬럼일 뿐. 1. 임베디드 DB는 변하는 것이 없고 java에서 편하게 쓰는 것일 뿐임. @Embeddable : 선언할 때, 나 추가될 수 있어 @Embedded : 모듈을 사용할 때, 나 추가됐어 상속이 아니다. 필드(객체)를 모듈화한 것임. 분리한 것임. 다른 곳에서도 재사용할 수 있음. 임베디드 : 기존에 있는 것에서 새로운 것을 추가하는 것임. 필드 하나하나를 접근해서 쓰지 않고, 묶어서 통채로 가져올 때 사용한다. 2. MappedSuperclass Inheritance : 상속관계, RDB에서도 상속관계 @Entity 사용 period : 부모x, 재사용하기 위함. 임베디드와 비슷한 성격. 상..