Limky 삽질블로그

프록시 지연로딩을 하기 위해서 jpa 내부적으로 껍데기 객체를 만들어야 한다. 이 껍데기 객체를 프록시 객체라고 한다. 프록시클래스는 실제클래스를 상속받아서 만들어지므로 실제 클래스와 겉모습이 같다 따라서 사용자 입장에서 이게 프록시인지, 실제클래스인지 구분하지 않아도 된다. 프록시객체 특징 - 처음 사용할때 한번만 초기화 - 프록시 객체를 초기화 한다고 해서 프록시객체가 실제객체가 되는게 아니고 실제객체를 만들고, 프록시객체에서는 실제객체에 대한 참조를 하게된다. 즉, 프록시객체를 통해서 실제객체에 접근하여 값을 가져온다 ㅎ -프록시객체는 원본 엔티티를 상속받은 객체이므로 타입체크시 ==을 지양하고 Instance of 를 쓰자 - getreference를 쓰면 프록시객체를 가져올 수 있다 - 초기화는..

내용 정리 https://incheol-jung.gitbook.io/docs/study/jpa/7 7장 고급 매핑 - Incheol's TECH BLOG 부모로부터 물려받은 매핑 정보를 재정의하려면 @AttributeOverrides나 @AttributeOverride를 사용하고, 연관관계를 재정의하려면 @AssociationOverrides나 @AssociationOverride를 사용한다. incheol-jung.gitbook.io 궁금한점 왜 식별자클래스는 Serializable 인터페이스를 구현해야할까? https://ocwokocw.tistory.com/138 JPA - 고급맵핑 - 복합키와 식별 관계 맵핑 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 참조: https://docs.jbos..

엔티티 연관관계를 매핑할 때에는 아래 3가지를 고려해야함 다중성 단방향, 양방향 연관관계의 주인 조금 더 구체적으로 설명하자면,,,,, 다중성 다대일 일대다 일대일 다대다 단방향, 양방향 테이블은 외래 키 하나로 조인을 사용해서 양방향으로 쿼리가 가능함으로 사실상 방향 개념이 없음 반면 객체는 참조용 필드를 가지고 있는 개체만 조회할 수 있음 단방향 : 연관된 객체 중에 한쪽만 참조용 필드를 사용해 한쪽 객체만 참조하고 있음 양방향 : 연관된 객체 모두 각자 참조용 필드를 사용해 양쪽다 객체를 참조하고 있음 연관관계의 주인 양뱡향 객체를 참조하고 있는 경우 관리 포인트가 2곳이기 때문에 키를 효율적으로 관리하기 위해 주인을 선택해야 함 주인이 아닌 곳에선 객체를 변경할 순 없고, 단순 조회만 가능 다대일..

엔티티 매니저 팩토리와 엔티티 매니저! JPA가 제공하는 기능은 크게 2가지이다. 엔티티와 테이블을 매핑하는 설계 부분 매핑한 엔티티를 실제로 사용하는 부분 이번 장에서는 매핑한 엔티티를 엔티티 매니저를 통해 어떻게 사용하는지 알아보자. 엔티티 매니저가 하는 일 엔티티를 저장,수정,삭제,조회 등 엔티티 관련된 모든 일을 처리 개발자 입장에서 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 됨 엔티티 매니저 팩토리 생성 코드 공장생성 비용이 상당히 큼(따라서 어플리케이션 전체에서 한 개만 만들고 공유하는 전략을 취함) EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook"); 공장에서 엔티티 매니저를 생성, 비..

회원 테이블 생성 CREATE TABLE MEMBER ( ID LONG AUTO_INCREMENT NOT NULL, -- 아이디(기본키) NAME VARCHAR(255), -- 이름 AGE INTEGER NOT NULL, -- 나이 PRIMARY KEY (ID) ) 회원 클래스 생성 import javax.persistence.*; @Entity @Table(name="MEMBER") public class Member { @Id @Column(name = "ID") private Long id; @Column(name = "NAME") private String username; private Integer age; public Long getId() { return id; } public void s..

JPA를 사용하지 않으면 생기는 문제점 (=SQL을 직접 다룰 때 발생하는 문제점) 객체지향과 데이터 중심의 데이터베이스 설계간 패러다임 불일치로 인해 개발자가 직접 객체의 필드값을 데이터 중심의 데이터베이스 구조에 맞게 로직을 짜야하고, CRUD(생성,조회,수정,삭제) 쿼리를 짜야한다. (반복적이고 지루한 일...) SQL에 의존적인 개발 (=물리적으론 엔티티와 데이터베이스를 분리했어도, 논리적으론 강한 의존관계를 가지고 있음) 등록,조회,수정 코드가 변경되거나, 연관 객체끼리 참조하는 경우 코드레벨에서 우리가 원하는 객체, 그리고 데이터 값을 보장받을 수 없기 때문에 결국엔 SQL를 까봐야 한다.. 상속 관계인 객체들을 저장하거나 조회하는 경우 원하는 타입만 따로 따로 조회하기 어렵고, 저장 또한 어..