생성자 인수 또는 설정 메소드를 통한 Entity의 id?

Question

UserEntity와 같은 엔터티가 있는데 id 속성이 db의 기본 키에서 파생 된 경우 - setId()과 같은 설정 메서드를 제공해야합니까?

• 는 DB
• 두 개 (또는 그 이상)의 UserEntities이 같은 id하지만 서로 다른 특성을 가진 언제든지 존재할 수있는 다른 UserEntities의 가능한 실수로 덮어 쓰기의 문을 엽니 다에 대한

  일부 인수 . (필자는 DB에서 3 개의 다른 사용자를 끌어와 같은 자신의 id 값을 설정 한 경우)에 대한

일부 인수 : 내가 id으로 UserEntity의 인스턴스가없는 경우

• 생성자에서 (setter 메서드가 있기 때문에), 임시/가짜/새 사용자 값을 가진 UserEntity 객체의 메서드를 사용할 수 있습니다. 먼저이를 유지하지 않고도 가능합니다.

는 세터를 제공 (생성자에 id 강제하지 않음), 또는 생성자에 id 강제하고, 세터를 삭제 하시겠습니까?

Answer 1

엔티티의 아이디 값은 지속성 계층에서 관리해야하며 이상적으로는 다른 것으로 설정할 수 없습니다. 지속성 계층은 지속성에 따라 새 ID 값을 할당하고 검색시 설정해야합니다. 또한, 신원에 액세스 할 필요없이 일시적인 (지속되지 않는) 엔티티를 사용할 수 있어야합니다. 아이디 값에 대한 신뢰할 수있는 소스가 없기 때문에 생성자를 통해 ID를 설정하면 문제가 발생할 수 있습니다. 외부 소스에서 ID를 할당 할 수있는 한 가지 예는 클라이언트가 ID가 UUID 인 새로운 영구 보존 엔티티를 요청하는 경우입니다.이 예제는 인위적입니다.

Answer 2

@johnnietheblack, 나는 개인 세터 및 단체 'IDS에 공공 게터을 만들 선호합니다. setter에 (필요한 경우) 유효성 검사가있을 것이고이 ID를 생성자에 독점적으로 설정합니다. 숫자 ID는 0 값으로 인스턴스화되어 라이프 사이클을 추적 할 수 있습니다.

에릭 에반스 (Eric Evans)의 도메인 기반 디자인은 마틴 파울러 (Martin Fowler)의 Enterprise Application Architecture 패턴이이 애플리케이션의 인프라에 깊이 관여 할 때 모델 도메인에 대해 이야기합니다. 나는 그들이 보완 자라고 믿는다.