특정 테이블안에 리스트 형식으로 데이터 저장하고 싶은 경우 RDBMS는 테이블 안에 리스트로 저장이 불가. 즉 다른 테이블로 빼내야 함 (빼낸 테이블은 Id와 컬럼 전부를 pk로 가진다.) Ex) //주소 @Embedded private Address homeAddress; //HashSet @ElementCollection @CollectionTable(name = "favorite_food", joinColumns = @JoinColumn(name = "member_id")) // FK로 잡기 위함 private Set favoriteFoods = new HashSet(); //ArrayList @ElementCollection @CollectionTable(name = "address", joinC..

Ex) Member 엔티티 //기간 Period @Embedded private Period workPeriod; //주소 @Embedded private Address homeAddress; Ex) Period @Embeddable public class Period { private LocalDateTime startDate; private LocalDateTime endDate; 생성자 Getter, Setter . . } - 클래스형태는 기존과 같게 하며 위와 같이 더 객체지향적으로 관리 가능 - 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다. @AttributeOverrides(속성하나), @AttributeOverride(속성 여러개) Ex) 임베디드 타입 Address 에 대하여..

@OneToMany(mappedBy = "parent",cascade = CascadeType.ALL) //childList까지 함께 persit 날려주겠다는 얘기 private List childList = new ArrayList(); 위와 같이 특정 필드에 cascade 설정을 할 경우 parent를 persist할 때 childList도 함께 persist 된다. Ex) Child child1 = new Child(); Child child2 = new Child(); Parent parent = new Parent(); parent.addChild(child1); parent.addChild(child2); em.persist(parent); 위와 같이 parent만 persist 해주어도 그 ..

- 실제 엔티티를 상속받아 만들어짐(따라서 겉모양이 같다) - 프록시 객체는 실제 객체의 참조(target)을 보관 - 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출 ** 프록시 객체는 원본 엔티티를 상속받음 . 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님. 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference() 호출해도 실제 엔티티 반환 Member findMember = em.getReference(Member.class, member); //빈 껍데기(프록시) //getUsername()시에 실제 쿼리 실행 -> 프록시 초기화 System.out.println("findMem..

관계형 데이터베이스는 상속관계가 존재하지 않음 1. 조인 전략 (최우선 선택, 복잡한경우) insert는 부모와 자식에 2번 / DTYPE으로 조인할 자식 엔티티 구분 @Inheritance(strategy = InheritanceType.JOINED) 2. 단일 테이블 전략(단순한 경우) 한 테이블에 합친다(JPA의 기본전략임) @Inheritance(strategy = InheritanceType.SINGLE_TABLE) 부모 엔티티에 적용 @DiscriminatorColumn //DTYPE 자식엔티티 적용 @DiscriminatorValue("A")//자식 엔티티 구분자 @MappedSuperclass - 상속관계 매핑은 아니지만 공통되는 속성을 사용하고 싶은 경우 사용!! - 엔티티도 아님(테이블..

- null 이면 안된다. - 유일해야 한다. - 자연키는 찾기 어려움 대체키를 사용하자! - 주민등록번호도 기본 키로 적절하지 않다. (왠만하면 의미 없는 값을 pk로 선택하자 ex) 1,2,3,4,..) - Auto Increment(IDENTITY) 아니면 Sequence object 둘중에 하나 쓰기 +) GeneratedValue 가 IDENTITY인 경우 예외적으로 persist 시에 디비에 바로 Insert query가 날라간다. (디비가 자동으로 생성한 값을 영속성 컨텍스트가 저장해야하므로) sequence는 커밋시에 query +) 데이터 중심 설계보다는 객체 지향 설계를 하자! (JPA에서는 엔티티간의 연관관계가 있을 경우 id 값을 참조하지말고 객체 자체를 참조!)

JPA에서 가장 중요한 2가지 - 객체와 관계형 데이터베이스 매핑하기 - 영속성 컨텍스트(엔티티를 영구 저장하는 환경) 엔티티매니저를 통해 영속성 컨텍스트에 접근 엔티티의 생명주기 - 비영속 : 객체를 생성한 상태 - 영속 : 객체를 영속성 컨텍스트에 저장한 상태 (EX) persist() / But, 커밋까지 해야 디비에 쿼리 날라감) - 준영속 : 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detach(entity), clear(), close()) - 삭제 영속성 컨텍스트의 이점 • 1차 캐시 • 동일성(identity) 보장 (같은 트랜잭션에서 비교시에) • 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind) • 변경 감지(Dirty Checking) • 지연 로..

관계형 DB가 아무래도 NoSQL보다는 메인! JPA-> ORM 프레임워크가 중간에서 매핑(객체지향과 관계형 DB사이) -> SQL 중심적인 개발에서 객체 중심으로 개발 -> 생산성 (CRUD 간단) - 저장(persist) 조회(find) 수정(set) 삭제 (remove) - DB에 다시 집어넣는 작업을 하지 않아도 됨 -> 유지보수 -> 패러다임의 불일치 해결 -> 성능 -> 데이터 접근 추상화와 벤더 독립성 -> 표준

변경방법 1. 병합(merge) -> 파라미터로 넘어온 준영속 상태의 엔티티 필드값으로 모든 필드를 변경 -> 세팅해주지 않은 필드값은 null로 변경되므로 굉장히 위험 2. 변경감지 -> 훨씬 나은 방법 -> 감지후 DB에서 알아서 업데이트 처리 해줌 / 원하는 속성만 선택해서 변경 가능 -> 컨트롤러에서 호출할 서비스 영역 안에 업데이트를 수행할 함수를 만든다. +) 엔티티 영역안에서 업데이트함수 만들고 서비스에서 업데이트를 위해 해당 함수 부르는 것이 낫다. (유지보수,추적 위해) 엔티티 클래스내에서 객체 생성, 변경, 조회등의 비즈니스 로직 생성한다. -> 서비스에서 호출 -> 컨트롤러가 서비스 호출

- 테스트는 따로 application.yml 설정파일 만들어주는 것이 좋음 -각 테스트 함수에는 @Test 어노테이션을 붙이며 만약 예외가 발생하는지 확인하고 싶은 경우에는 @Test(expected = IllegalStateException.class) 와 같이 해당 예외에 대한 어노테이션을 만들어준다. - 테스트 코드 틀 예시 @RunWith(SpringRunner.class) @SpringBootTest @Transactional // 테스트 끝날때 다시 rollback 해버림 public class MemberServiceTest { @Autowired MemberService memberService; @Autowired MemberRepository memberRepository; @Test..

-의존관계 주입의 경우 생성자 주입을 지향 후에 변경이 불가능한 안전한 객체 생성이 가능하기 때문. - 생성자가 하나면 @Autowired 생략 가능 - 변수에 final 붙여서 후에 수정 불가능하도록 하는 것이 좋음 - Repository에서 사용하는 EntityManager는 @PersistenceContext를 통해 사용가능하지만 SpringBoot에서는 @Autowired도 가능 - final을 붙인 변수를 Lombok의 @RequiredArgsConstructor 를 통해 생성자 생성/주입해주면 일관성있고 깔끔하게 코드 정리가 가능하다. 생성자 주입을 적용한 Repository 예시) @Repository @RequiredArgsConstructor public class MemberReposi..

1. 가급적이면 setter 사용하지 말자. - 변경 포인트가 많아서 유지보수가 어려워짐 2. 모든 연관관계는 지연로딩으로 설정 - LAZY로 설정!!! EX) @ManyToOne(fetch = FetchType.LAZY) 3. 컬렉션 바로바로 세팅 (선언과 동시에 초기화) - null 문제 방지 위해 4. 양방향 연관일때는 연관관계 편의 메소드를 통해 값 세팅 - 연관관계의 주인만 값을 가지고 있을 수는 없으므로 (DB에는 주인만 가져도 ok) 5. 최대한 어디에서 dependency없이 순수하게 놔두기(핵심 비즈니스 로직만! 화면 관련 로직은 Form 객체 또는 DTO 사용) +) manytomany는 왠만하면 사용x, 일대다, 다대일로 나누기 +) API 만들때에는 절대 엔티티를 외부로 반환(노출)..