전체 글
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 6. 다양한 연관관계 매핑
다양한 연관매핑을 알아보자고 했는데 사실 다대일, 일대다 일대일, 다대가가 전부다. 특히 거의 다대일만 쓰고 다대다는 쓰지 말자. 그럼 어떻게 해야하는지는 이따 나온다. 다대일 방 db의 경우, 방향이라는 개념이 없고, 다른 테이블이랑 연관하려면 자바 객체와 달리 한쪽만해도 연결이 된다. join을 그쪽으로 하면 그냥 된다. 그래서 객체 연관관계와 테이블 연관관계의 차이가 생기는 것. 근데 team는 가지면 안되냐? 할 수 있지만 team에 새로운 member를 넣을때마다 안은 리스트로 만들어서 증가해야 하고... 거기다 그걸 위한 새로운 team을 만든다고 해도 그건 중복이다. 그냥 설계가 잘못된거임. 그래서 db 설계상 team쪽에 들어갈 수 없다. 여기까지 다대일은 전에 배운 내용이다. 일대다부터 ..
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 5. 연관관계 매핑 기초
전 마지막에 id로 해서 가져와 데이터 지향이 되서 결국엔 객체지향적으로 못하는 문제가 있었는데 이를 해결해본다. 그 전에 사실 객체지향 자체에 대해 이해하는게 더 중요함. 이걸 이해하는데 시간이 더 들거다.. https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=60550259 객체지향의 사실과 오해 위키북스 IT Leaders 시리즈 23권. 객체지향이란 무엇인가? 이 책은 이 질문에 대한 답을 찾기 위해 노력하고 있는 모든 개발자를 위한 책이다. www.aladin.co.kr https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=193681076 오브젝트 역할, 책임, 협력에 기반해 객체지향 프로그램을 설계하고 구현하는 방법..
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 4. 엔티티 매핑
JPA에서 중요한게 영속성 개념이랑 엔티티 매핑 개념이다. 여기선 이게 뭔지 좀 소개한다. @Entity는 JPA에서 관리해주는 클래스다. 그래서 JPA를 사용해서 테이블과 매칭할 때는 @Entity를 붙여야 한다. 주의점은 얘가 동적인 작업을 내부에서 수행하기 때문에 기본 생성자는 만들어야 하고, fianl, enum, interface, inner는 안되고 필드 안에서 final 사용은 안된다. 속성은 name이 있는데 jpa 내부에서 구분하기 위한 거다. 그냥 기본값 쓰거나 겹치면 바꾸면 된다. @Table이 붙은건 엔티티와 매핑할 테이블을 지정해주는 것. @Entity만 해도 테이블을 만들지만 테이블 이름을 다르게 해야 하는 등의 문제가 있을 때 속성을 직접 바꿔줄 수 있다. @Entity이 붙은..
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 3. 영속성 관리 - 내부 동작 방식
JPA에 대한 개념적인 얘기를 좀 할거다. JPA에서 가장 중요한 2가지가 ORM이랑 영속성 컨텍스트인데, 이 중 영속성 컨텍스트 개념을 배울거임. 전 시간에 실습한 내용을 보면 엔티티메니저 팩토리가 트랜잭션을 실행할 때마다 그 트랜잭션을 실행하는 엔티티 메니저를 만들어야 하고 이 메니저로 트랜잭션을 실행한다. 그래서 저장할 때 persist란 함수를 썼는데 사실 persist 할 때 바로 저장이 되는게 아니다. 실제로는 커밋을 수행해야 저장이 된다. 그럼 왜 persist할 때 저장하는것 처럼 얘기하고 persist를 하면 무슨 일이 일어나는 건가. 여기서 영속 개념이 나온다. 엔티티메니저니 뭐니 아무것도 없이 평소처럼 그냥 쌩 자바로 객체를 만들었을 때. 정말 아무 상태도 아니지만 영속 개념을 설명하..
자바 ORM 표준 JPA 프로그래밍 - 기본편 - 섹션 2. JPA 시작하기
옛날 강의라 maven 쓴다. 근데 얘는 설정법이 좀 복잡한듯. java persistence api인 인터페이스를 구체화한 게 hibernate이다. 그럼 각 db에 따라 각 언어마다 다른 방언이 있는데 그걸 hibernate가 구체화 해준다. 나머진 별로 안중요한듯. 폴더 경로가 정해져 있어서 꼭 resources 바로 밑에 META-INF 밑에 persistence.xml로 파일명을 만들어야 한다. maven은 이걸로 db랑 연결한다. 엔티티를 만들긴 하지만 아직까지 실습 단계에선 테이블까진 만들어주진 않는듯. 테이블은 직접 db에 들어가서 create로 만들어준다. 그럼 할 준비가 됐는데, 방식은 엔티티 매니저를 만드는 애로 엔티티 매니저를 만드는데, 각 트랜잭션 마다 엔티티 메니저 하나씩 부여하..
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션7. 웹 계층 개발
뷰를 위한 html들 넣어준다.. 볼만한건 fragments/header .. 로 이하로 한다는 거 form 받는거 구성 타임리프는 아니까 그냥 복습 겸... @Valid가 있으면 맞는지 검사하고 만약 바로 뒤의 매개변수로 bindingresult 있으면 에러 안띄우고 안에서 처리해서 다시 html에 넘길 수 있고 등.. 리스트.. 절대 주의할 점은 만약 api로 한다고 하면 저렇게 엔티티 자체를 그대로 넘기면 안된다. 지금은 실습이고 어차피 서버 사이드 렌더링이라 크게 상관 없어서 하는거지만. 하지만 서버 사이드 렌더링도 Dto를 만들어서 하는게 좋다. 아이템 상품목록 상품 수정은 위에서 수정용 링크로 가게 한다. 수정 해주는게 중요함. 그리고 save를 타고 가다보면 merge를 사용하는데 실무에선 ..
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션6. 주문 도메인 개발
이제 아이템을 주문할 때 창고에 있는 아이템 개수는 줄어들고, 주문목록엔 생겨나고, 장바구니 역할을 하는 OrderItem의 총 가격 등을 계산하고.. 같은 핵심 비즈니스를 해볼거다. @Entity @Table(name = "orders") @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) // protected로 생성자를 막음. createOrder를 사용하도록 함. public class Order { @Id @GeneratedValue @Column(name = "order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "member_id")..
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션5. 상품 도메인 개발
별거 없다. 이론 설명은 전 섹션에서 다 했기 때문에. 처음 보는 개념으론 서비스가 아니고 왜 엔터티에 함수를 넣느냐이다. 이유는 엔터티 안의 변수를 직접적으로 다루는 거는 엔터티의 함수로 남겨놔야 유지보수가 편하다는 짬 섞인 경험이다. 그리고 좀 더 직관적이기도 하고. 커스텀 예외의 경우 순수성을 유지하기 위해 런타임으로 만든 듯 하다. 레퍼지토리는 db랑 직접 소통하는거고 전에 했어서 막 별거 없다. 볼만한건 merge로 아이템이 있어도 강제로 밀어붙이는거.
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션4. 회원 도메인 개발
섹션3의 애플리케이션 구현 준비 이제 섹션 4에선 db랑 소통하는 레퍼지토리 짜고, 서비스 짜고, 이걸 테스트하는 코드를 짜본다. EntityManager를 저렇게 정의만 해도 lombok이 final 붙은건 가져오기끔 @RequiredArgsConstructor를 한다. 사실 이걸 위해 @Autowired쓰고 아니면 생성자에 붙이고.. 해야 되는데 계속 더 간단한 방법이 나온다. EntityManger의 createQuery의 특이점은 안의 내용이 결국은 sql문으로 변환되지만 여기선 모델이 아닌 엔터티를 받는다는데 있다. @Service @Transactional(readOnly = true) // 읽기 전용이면 성능이 좋아짐 @RequiredArgsConstructor // final이 있는 필드만..
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 섹션2. 도메인 분석 설계
쇼핑몰 만든건데 요구사항 이해한 내용이 너무 없는데, 이론편을 배우고 실전편을 배우는 걸로 진행을 해야 해서 그런 것 같다. 일단 이런게 필요하겠구나 하고 대략적으로 구성한 다음에 속성은 뭐가 필요할지, 그 속성이라면 테이블은 어떻게 할지 구체적으로 정하는 것 같다. 여기에서 강조한건 다대다는 운영에서 제약이 많기 때문에 안좋다. 또 양방향 관계도 양쪽이 서로를 참조하고 있어서 누가 주인인지 명시해야 해서 방침을 정하는 등 더 복잡해지고 이점은 단방향으로만 가능한 경우가 많아서 안하는게 좋다. 여기서 강조한건 외래키를 가지고 있는 애가 연관관계의 주인이라는 것. 다대일 에서 일쪽이 외래키를 가지고 있으려면 리스트 안에 등록하고 난리나니까 다쪽에 외래키로써 누가 주인인지 들고 있는게 db 구조다. 다대다 ..