BaseEntity 사용 여부 결정

[ddaaac]

BaseEntity 사용 여부 결정

[KIMSIYOUNG]

BaseEntity 사용하자 및 이유

• Spring Data Jdbc는 의존성이 강해지는 것이 아니면 계속 추가적으로 지원을 할 것 같음. 그런 의미에서 baseEntity를 최적화해서 만드는 방법도 나름대로 곧 제공할 것 같음. 결국 쓰게 되지 않을까?
• createAt과 updatedAt 필드가 중복되는 것이 @PersistenceConstructor 가 있는 것 보다 보기 싫음.
• 사용하지 않는 경우 성능상 얻는 이점이 크지 않을 것 같음.
• Noarg 는 BaseEntity 에 있기 때문에 문제되지 않을 것 같음.
• 생성자가 private으로 막히기 때문에 2개(빌더와 정적팩토리)로 생성을 제한할 수 있을 것 같음 (package-private은 선택지가 3개(빌더, 생성자, 정적팩토리) 라는 생각 때문에

[JinJuMoon]

BaseEntity를 사용하지 말자

BaseEntity가 hibernate의 인터페이스를 가져왔다면 Spring Data JDBC에는 최적화되어있지 않을 것 같다.
Spring Data JDBC 관련 자료가 적기때문에, 공식 Reference에서 선호하는 방향으로 개발하는 것이 향후 변경의 여지가 적지 않을까?

+) createAt과 updatedAt 필드가 중복되는 것이 줄이려면 우리가 만든 BaseEntity를 사용해도 좋을 것 같다.

[ddaaac]

잘못 닫았어요... 죄송합니다 😒

그리고 BaseEntity는 제가 임의로 만든 클래스입니다! hibernate와는 관계가 없어요 😄

[dks301]

고민 되는 점

• 장점
  1. createAt, updatedAt과 같이 거슬리는 반복을 없앨 수 있다.
• 단점
  1. is-a 관계가 아니라서 상속의 원칙에 위배된다.
  2. @persistnaceEntity 사용을 하지 않는 spring data jdbc 코어 아이디어에 위배된다. (성능에도 좋지 않다.)
  3. 우리가 아닌 다른 개발자가 코드를 볼 경우에 특정 Entity의 필드를 한 번에 알 수 없다.

결론: 사용하지 말자

• 장점보다 단점이 많을 것 같고, 실제 우리가 작성하는 코드량은 거의 다를바가 없는 것 같다. 카일 말대로 추후에 Spring data jdbc가 최적화된 Base Entity 사용법을 제공할 때 리팩토링을 하는 것이 좋아 보인다. 또한, BaseEntity를 사용하다가 반대로 리팩토링을 하는 것이 더 어려워 보임.

[fucct]

BaseEntity를 사용하지 말자

• createdAt과 updatedAt 필드 중복을 제거하기 위해 너무 많은 코드가 발생함
• Entity 내에 생성 시간과 수정 시간이 필드로 명시되어 있는게 오히려 가독성이 좋다고 생각함
• Spring data jdbc 공식 문서에선, 여러 생성자를 만들기 보단 단 하나의 PersistenceConstructor 와 정적 팩터리 메서드로 구현하길 권장함

[ddaaac]

BaseEntity를 사용하지 않는 것으로 결론짓겠습니다!