일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 공부일지
- 데이터베이스
- softeer
- SW봉사
- 코틀린
- 소프티어
- 시나공
- java
- SQL
- kotlin
- programmers
- 파이썬
- C++
- 백준
- CJ UNIT
- 1과목
- 코딩봉사
- python
- 알고리즘
- 자바
- 회고
- 문제풀이
- 프로그래머스
- BFS
- MYSQL
- 백준알고리즘
- 정보처리산업기사
- 코딩교육봉사
- 스프링
- 백준 알고리즘
Archives
- Today
- Total
JIE0025
[개선] 엔티티에 사용되었던 무분별한 어노테이션 개선 과정 본문
728x90
✅ Category Entity에 사용되었던 어노테이션
리팩토링 이전에는 어노테이션이 무분별하게 사용되고 있었다.
@Setter
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Builder
잘 알지 못하고 마구 사용한 것을 반성하며 이것을 개선하기 위해 먼저 Setter와 AllArgs를 삭제했다.
- Entity 클래스이고, @id 컬럼의 GenerateType이 IDENTITY이기 때문에, AllArgs은 필요없다고 판단했고
- Setter 역시 클래스 레벨에 사용하는게 좋지 못하다는 것을 들었고, 자유로운 객체 생성시엔 @Builder를 남기는게 맞다고 판단했다.
그렇게 @NoArgsConstructor(access = AccessLevel.PROTECTED)과 @Builder 만 남게 되었고
이 경우 에러가 발생한다.
기본 생성자의 접근 제어를 PROTECTED로 설정할 경우 무분별한 객체 생성에 대해 한번 더 체크할 수 있는 수단이 되어 좋다는 것을 봐서 @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용 하는게 좋을것 같으면서, 에러가 발생해서 나중에 따로 정의한 생성자에 Builder를 추가하는 방향으로 바꿔놓았다.
이 방법이 최선인지 모르겠어서 일단 PROTECTED를 주석 처리 시켜 놓았다 ㅠㅠ
나중엔 Mapper인터페이스를 추가하다보니 스프링이 만들어주는 MapperImpl이 Setter를 사용하고 있어서 다시 Setter를 붙히게 되었고..
복잡하다 아주
어노테이션 사용에 있어 최선의 선택이 무엇인지 아는게 어렵다
여러명한테 피드백 받아보고 글 업데이트 해야지!
'백엔드 > 스프링, 스프링부트, JPA, Spring Webflux' 카테고리의 다른 글
[JPA] 5장 연관관계 매핑 기초 (0) | 2023.01.04 |
---|---|
[JPA] 4장 엔티티 매핑 (0) | 2023.01.02 |
[리팩토링] EntityManager → QueryDSL을 이용한 getCategories (2) | 2022.12.22 |
[Spring] 로깅 (Logging) (0) | 2022.12.22 |
[Springboot][개발] FLAG - Category CRUD 1차 완성 (Merged) (0) | 2022.12.21 |