작성
·
74
·
수정됨
0
1. 강의 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 아니오
3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예
[질문 내용]
안녕하세요!
다른 분이 이미 저와 비슷한 내용의 질문을 하시긴 했는데,
아직 잘 이해가 안 가서 여쭤봅니다!
Q. 아래 사진처럼, Address의 필드들을 그냥 AddressEntity에 다이렉트로 선언해서 Entity 그 자체로 사용해도 될 것 같은데, 왜 값 타입을 별도로 만들어서 포함하도록 하는 건가요?
응집성 및 재사용성 그리고 불변성을 보장하기 위함인가요? 그런데 만약 불변성을 보장하기 위함이라면, 아래 사진처럼 값 타입과 마찬가지로 Setter를 그냥 막아두면 되지 않나 해서...
제가 어떤 부분을 놓친 건지ㅠ
다른 이유가 있다면, 너무 궁금합니다!
답변 1
0
안녕하세요. WTeobp님, 공식 서포터즈 코즈위버입니다.
엔티티를 분리한다는 건 데이터베이스의 테이블을 분리한다는 의미입니다. 즉 '주문'과 '배송지' 이 둘을 다른 테이블에서 관리한다는 의미가 됩니다. 보통 주문에는 배송지 정보가 반드시 필요하며 딱 하나만 존재합니다. 그리고 배송지 정보는 '주문'을 구성하는 필수요소로 볼 여지가 크며 이를 분리하여 관리해야 할 이유는 적습니다.
그래서 주소를 주문엔티티와 분리하여 관리하는 것 보단 주문엔티티 내의 필드로 선언하여 사용합니다. 그런데 주문에는 배송지에 관한 필드 외에도 무수히 많은 필드가 있을 수 있습니다. 그러면 각각의 필드가 어떤것끼리 관련있고 어떤것은 관련이 없는지 그룹을 분리해서 관리하는것이 유리한데요. 그럴때 값타입을 활용하여 필드들을 논리적으로(+ 코드상으로도) 분리하는 방법을 적용할 수 있습니다.
감사합니다.
안녕하세요 WTeobp님!
어떤 ‘개념’을 엔티티로 관리한다는 것은 그 개념이 비즈니스의 핵심 요소임을 의미합니다.
가령 쇼핑몰의 경우 '회원', '상품’이 핵심이며 이를 엔티티로 구성합니다.
그리고 이런 엔티티들의 ‘관계’를 통해 새로운 개념이 생기는데요, ‘주문’이 그러한 예시입니다. (‘회원’이 ‘상품’을 만나면 ‘주문’이 생기므로)
주문은 여러가지 조건을 만족해야 합니다.
다른 주문과 구별되는 고유한 키를 소유해야 하며, 주문의 상태도 관리해야 합니다.
위의 조건을 만족하기 위해, 주문은 단순 값객체가 아닌 엔티티 레벨로 관리해야 한다는걸 알 수 있습니다.
이제 주문과 배송정보를 보겠습니다.
배송정보는 주문의 구성요소로 반드시 필요한 값입니다. 그러나 별도의 엔티티로 관리되어야 할 대상인지는 생각해보아야 합니다.
배송지 주소는 단순 값이며 상태를 관리해야 하는 대상은 아닙니다.
그래서 일반적으로 배송주소는 별도의 엔티티로 관리하지 않고 ‘주문’ 엔티티의 구성요소로 관리합니다.
답변 감사합니다!
그런데 해당 강의(값 타입 컬렉션)에서는 '주문'과 관련된 내용은 안 나오는데,
혹시 코즈위버님께서 다른 강의와 착각하신 건지,
제가 이해를 잘못하고 있는 건지 잘 모르겠습니다.
먼저 다시 질문드리기에 앞서, 제가 해당 강의 내용을 통해 이해한 내용은 다음과 같습니다.
값 타입 컬렉션은 식별자가 존재하지 않다 보니, JPA 입장에선 추적이 어렵다.
그래서 값 타입 컬렉션에 변동이 생겼을 때 JPA는 그냥 전부 제거한 다음,
새롭게 추가하는 방식으로 동작하게 된다.
이러한 단점을 보완하기 위해, 값 타입 컬렉션 대신 별도의 Entity를 만들어서
해당 값 타입을 감싸 식별자의 역할을 대신하게 하고, OneToMany 연관 관계를 설정한다.
여기서 궁금한 점은
"이 Entity는 추후에 다른 내용의 필드들이 추가될 것 같지도 않고,
단순히 값 타입을 감싸서 식별자의 역할만 하는 것으로 보이는데...
이럴 거면 애초에 Address를 값 타입으로 만들 필요 없이
그냥 Entity로 만들면 되는 거 아닌가?"였습니다.
참고로 이전 질문의 사진은 본래 강의 내용 코드를 수정해서
제 의도(값 타입을 만들지 않고, Entity 그 자체로 사용)를 보여드렸던 것이고,
아래의 사진이 본래 강의 내용 코드입니다!