객체가 자신의 ID를 알아야합니까?

obj.id상당히 흔하게 보이며 물체 자체에 대해 알 수있는 범위 내에있는 것 같습니다. 내 객체가 왜 자신의 ID를 알아야하는지 묻습니다.

그것을 가질 이유가없는 것 같습니까? 그것이 존재하는 주된 이유 중 하나는 그것을 검색하기 때문에 내 저장소 는 그것을 알아야하므로 데이터베이스 상호 작용에 사용해야합니다.

또한 ID가 페이로드에 맞지 않는 것처럼 보이지만 URI와 객체에 포함시키는 것이 더 어려워지는 RESTful API를 위해 객체를 JSON으로 직렬화하려는 문제가 발생했습니다.

객체가 자신의 ID를 알고 있어야합니까? 그 이유는 무엇?

업데이트 : 용어

1. id : 객체의 식별자 속성. 데이터베이스 용어로 대리 키는 자연 키가 아닙니다.
2. 개체 : 개체 또는 시스템 내에서 고유하게 식별 가능한 개체입니다.

짧은 답변 : 개체 내에 개체 식별자를 포함시키는 것은 반드시 참조되어야합니다.

개체 모음을 사용하고 개별 개체 / 엔티티를 참조 할 계획이있는 시나리오의 경우 식별자가 포함되어야합니다. 그러나 자연적인 키 / 식별자와 같은 DateTime것이 그러한 요구를 인위적으로 충족시킬 수있는 경우가있을 수 있습니다 .

또한 DTO를 객체의 경량 컨테이너로 사용하면 객체 식별자 자체를 건너 뛰거나 포함 할 수 있습니다. 실제로이 모든 선택 사항은 실제로 비즈니스 사용 사례와 요구 사항에 따라 다릅니다 .

편집 : 객체를 식별하려면 식별자가 필요합니다. 이 식별자는 대리 ID, 날짜-시간, 안내 등이 될 수 있습니다. 기본적으로 고유 한 방식으로 다른 사람의 객체를 식별하는 모든 것입니다.

내 답변을 귀하의 질문과 같이 추상적으로 남겨두기 위해 실제로 자신의 질문에 답변했다고 생각합니다.

필요한 경우 객체는 자체 ID를 알아야합니다.

객체는 필요하지 않은 경우 자신의 ID를 알 수 없어야합니다.

지적했듯이 개체가 불편하거나 불필요하여 개체의 ID를 유지하거나 알 수없는 경우가 있습니다. 그러나 객체가 자신의 ID를 인식하는 것이 더 편리한 다른 경우가 있습니다. 용도에 맞게 개체를 코딩하십시오.

ID를 포함하는 것이 일반적이지만 사전 (예 : 각 ID가 해당 ID를 알고있는이 개체를 쉽게 검색 할 수있는 방식으로 각 개체가 해당 ID와 연결된 데이터 구조)을 사용하는 것도 일반적입니다. 그것.

예를 들어 두 가지 방법으로 API를 만드는 경우 :

• http://api.example.com/products/

  제품 ID 목록을로드합니다.

• http://api.example.com/product/452/

  ID 452의 제품을로드합니다.

그런 다음 두 번째 요청의 JSON 응답에서 ID 452를 다시 보낼 필요가 없습니다. API 사용자는 이미 ID를 알고 있습니다.

나는 이것이 주관적이며 당신의 디자인에 달려 있다고 생각합니다.

대부분이 디자인은 활성 레코드 에서 나온 것으로 보입니다 . 활성 레코드에는 엔터티에 데이터베이스 작업을 수행하는 메서드가 있으므로 해당 데이터베이스 식별자도 알아야합니다.

객체에이 데이터를 저장 하는 데이터 매퍼가 있는 리포지토리 와 같은 다른 패턴을 사용 하는 경우 불필요하고 부적절해질 수 있습니다.

예를 들어 Person물체를 생각해보십시오 . 가족 내에서 고유하거나 고유하지 않은 이름이 부여됩니다. 인구가 증가함에 따라 더 큰 이름은 더 이상 고유하지 않으므로 점점 더 큰 시스템에 대한 대리 식별자를 생각해 냈습니다. 예 : 운전 면허증, 주민등록번호. 본인은 아이디를 부여받지 않고 태어 났으며,이 아이디는 모두 신청해야합니다.

이들 중 대부분은 보편적이지 않기 때문에 소프트웨어에 적합한 기본 키 / ID를 만들지 않습니다. 적어도 특정 시스템 외부가 아닌 SSN은 사회 보장국에 독특하고 일관성이 있습니다. 우리는 일반적으로이 정보를 제공하는 사람이 아니기 때문에 정보를 제공하는 id것이 아니라 그들이 나타내는 데이터를 예로들 것 SSN입니다. 때로는 DriversLicense운전 면허증이하는 모든 정보를 포함 할 수있는 완전한 구성 객체를 포함하기도합니다 .

따라서 모든 일반 ID는 시스템의 대리 키이므로 메모리 참조에서 대체 할 수 있으며 레코드 만 더 쉽게 찾고 유지하기 위해 id 만 포함 할 수 있습니다.

id는 개념적 데이터의 조각이 아니기 때문에 도메인에서 나오지 않기 때문에 (일반적으로) 객체 내에 속한다고 의심합니다. 오히려 고유 한 아이덴티티를 나타내는 다른 방법이없는 객체를 식별하는 것이 목적으로 유지되어야합니다. 이것은 저장소 / 수집에서 쉽게 할 수 있습니다.

소프트웨어에서 객체를 목록으로 나타내거나 유지해야하는 경우 리포지토리 / 수집 객체 또는 이와 연관된 다른 객체에서 간단히 수행 할 수 있습니다. 데이터 매퍼로 전달할 때 (별도 인 경우) 간단히 전달할 수 있습니다 .update( id, obj ).

면책 조항 : 나는 엔터티 내에 ID를 포함하지 않는 시스템을 아직 구축하려고 시도하지 않았으므로 자신을 잘못 증명할 수 있습니다.

GlenH7이 의견에서 언급했듯이, 많은 사람들이 당연한 것으로 생각하는 것에 도전하기 때문에 좋은 질문입니다. 그러나 내 생각에 ID를 남기는 것이 개념적으로 순수한 것처럼 보일지라도 실용적인 방법은 가능한 한 많은 시스템 계층에 걸쳐 객체로 ID를 유지하는 것입니다. 비용은 거의 들지 않지만 문제가 발생하기 시작하면 편리합니다.

개인이 자신의 개인 식별 번호, 운전 면허 번호 또는 해당 지역에서 사용중인 다른 식별자를 알 필요가없는 것처럼 엔티티는 ID를 알 필요가 없습니다. 당신은 확실히 그것 없이도 할 수 있습니다. 그러나 만일의 경우를 위해 어떤 종류의 신분증을 가지고 다니는 것이 현명합니다.

객체에 대해서도 마찬가지입니다. 데이터 액세스 계층의 복잡성에 관계없이 객체는 궁극적으로 특정 데이터베이스 항목에 매핑됩니다. 이 항목은 객체의 ID로만 고유하게 식별 할 수 있습니다. 그렇다면 UI 코드 디버깅, 비즈니스 계층의 번호 크 런칭, 저장소 자체 또는 웹 서비스의 종속 시스템에 관계없이 언제든지이 정보를 사용할 수 있기를 바랍니다. 또는 해당 문제에 대한 오류 로그를 탐색하는지 여부입니다.

귀하의 경우, DB에서 데이터를 가져 와서 웹 서비스를 통해 푸시하는 경우 ID를 그대로 두는 것이 옳은 일 일 수 있습니다. 나는 그것이 일반적인 경우를 유지하는 것보다 더 의미가 있다고 믿지 않습니다.

저장소 컨텍스트에서 ID 만 알고 있으면 객체에 ID를 저장할 필요가 없습니다.

객체를 컨텍스트 외부의 코드, ID로 객체를 요청하지 않았으므로 아직 알지 못하는 코드로 전달할 때 상황이 변경되지만 목적에 관계없이 (예 : 목록에 배치하기 위해) ID가 필요합니다 저장소에서 나중에 또 다른 코드로 요청되는 ID).

이 경우 두 가지 옵션이 있습니다.

• 저장소 컨텍스트와 ID가 필요한 함수 사이의 전체 함수 체인에 새로운 함수 인수 'id'를 도입하십시오.

• 객체에 ID를 포함

이러한 대부분의 경우 객체 내부에 ID를 저장하는 것이 더 나은 솔루션입니다. 또한 예상치 못한 장소에서 ID가 필요할 때 코드 변경을 줄이며 때로는 디버깅에 도움이 될 수 있습니다.

내가 할 때 그렇게하는 이유입니다.