티스토리 뷰

카테고리 없음

TIL - 2023.07.31

나죽나강 2023. 7. 30. 22:04

 

Hibernate vs Spring Data JPA 


스프링 진영에서는 Spring Data JPA를 개발했고 이를 권장하고 있다. 

'JPA < Hibernate < Spring Data JPA' 구조로 되어 있으며 이렇게 한단계 더 감싸 놓은 이유는 크게 2가지 이다.

1. 구현첸 교체의 용이성

2. 저장소 교체의 용이성

 

Spring Data 하위 프로젝트들은 기본적인 CRUD 인터페이스가 똑같다. 따라서 Spring Data JPA, Spring Data Redis, Spring Data MongoDB 등등은 save(),findAll()의 인터페이스를 가지고 있기 때문에 저장소나 구현체를 변경하여도 기본적인 기능은 변경하지 않아도 된다.

 

 

 

 

Entity Class 위 어노테이션 순서


Entity Class 위 어노테이션의 순서를 주요 어노테이션을 클래스에 가깝게 두자. 

일반적인 롬복 어노테이션은 클래스에서 멀리 위치하고 @Entity처럼 JPA어노테이션은 클래스에 가깝게 두자.

주요 어노테이션을 쉽게 파악할 수 있을 뿐만 아니라, 롬복처럼 쉽게 교체가 되거나 제거하는 어노테이션을 멀리두면 삭제할때도 편리하다.

@Getter
@NoArgsConstructor
@Entity
public class Member(){

}

 

 

Entity와 Repository


Entity클래스와 기본 Entity Repository는 함께 위치해야 한다. 둘은 아주 밀접한 관계이고, Entity클래스는 기본 Repository 없이는 제대로 역할을 할 수가 없다. 나중에 프로젝트 규모가 커져 도메인별로 프로젝트를 분리해야 한다면 이때 Entity클래스와 기본 Repository는 함께 움직여야 함으로 도메인 패키지에서 함께 관리한다. 


> 개인적인 생각

Entity와 Repository가 하나의 패키지안에 꼭 구성되어야 할 필요는 없지만, 하나의 Entity는 하나의 Repository를 가져야 한다고 생각한다. 그 이유는 위에 있는 저자의 생각과 동일하게, Entity와 Repository는 밀접한 관계이며 하나의 Repository에서 Entity의 행위를 관리한다면 저장소를 변경할때 유지보수성이 더 좋아지며 코드 위치를 파악하기도 좋을것 같다. 

 

 

 

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함