Entity에 대해 질문이 있습니다.
먼저 재미있게 강의 잘보고 있습니다. 감사합니다.
프로젝트에서 storage 모듈을 보다가 모든 entity가 status를 갖는다는 것을 알게되었습니다.
class xxEntity():BaseEntity()
// base entity가 status를 갖고 있고
// 위의 코드는 상속이라고 알고있습니다(AI로 확인해봤는데 만약 아니라면 민망할것같네요...)모든 entity가 상태가 필요한가? 하는 생각이 들어서요. 아니면 status를 기본으로 설정하면서 어떤 장점을 의도하려고 하신건지 궁금합니다.
답변 1
1
비비비비빅님 강의 재밌게 봐주시고 질문 주셔서 감사합니다!
AI로 분석에 적극 쓰시다니 아주 좋은 모습입니다! (코드 형태는 설명주신게 맞습니다)
기본값으로 넣은 이유는 대부분 서비스 운영시 예기치 못하게 데이터의 상태를 처리해야 할 경우가 있습니다,
서비스 운영 및 데이터 추적을 위해 일반적으로 Hard Delete(Delete 쿼리)가 불가능하기 때문에 대부분 데이터는 status 기반으로 삭제 플래그 처리(Soft Delete)를 하는 편입니다!
그래서 제 경우는 엄청 유의미하게 쓰이지 않더라도 상태에 대한 것을 특별한 사유가 있지 않는 테이블을 제외하고는 모두 추가해두는 편입니다!
또한 더 장기적인 관점에선 추후 데이터 마이그레이션이나 운영 이슈 처리 시에도 이 상태 컬럼들을 유용하게 쓰일 수 있습니다 (지금 적당한 예제가 생각이 안나네요ㅎㅎ;)
다만! 누가봐도 정말 상태가 필요 없는 테이블이라면 BaseEntity 를 안 쓰고 id나 시간 정보를직접 구성하던가, 그런 Entity 가 많다면 NoneStatusEntity 같은 클래스를 만들어서 사용하기도 합니다 :)
모쪼록 답변이 도움 되셨길 바라며 완강까지 잘 부탁드리고 수강평도 부탁드립니다!
추가 질문은 편하게 주시길 바랍니다! 감사합니다!
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
47
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
73
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
80
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
75
2
새로 개발한다면 구현 순서
1
133
1
의존 방향에 대한 고민
1
122
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
95
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
83
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
96
1
PG 결제 승인 로직
1
128
2
QnA에서 Join 필드 표현법
1
88
1
결제서비스 콜백 동시성문제 가능성
1
106
2
굿
1
107
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
135
2
도메인 객체와 엔티티 객체 사용
1
137
2
CouponService 의존성 의문
1
96
2
상품 목록 조회 고도화 질문
1
111
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
제품상세 코드 느끼기
1
144
2
격벽의 순환 참조(?)
1
113
2