オブジェクトは自身のIDを知っている必要がありますか？

obj.idはかなり一般的であり、オブジェクトがそれ自体について知ることができる範囲内に収まるようです。私は自分のオブジェクトが自分のIDを知っている必要がある理由を尋ねています。

それを持っている理由がないようですか？それが存在する主な理由の1つはそれを取得することです。したがって、私のリポジトリはそれを知る必要があり、したがってデータベースとの対話に使用する必要があります。

また、IDがペイロードに収まらないように見えるRESTful APIのオブジェクトをJSONにシリアル化したいという問題に一度遭遇しました。

オブジェクトは自身のIDを知る必要がありますか？なぜですか？

更新： 用語

1. id：オブジェクトの識別子属性。データベース用語では、代理キーは自然キーではありません。
2. オブジェクト：エンティティ、またはシステム内で一意に識別可能なオブジェクト。

短い回答：オブジェクト識別子を参照する場合は、オブジェクト識別子をオブジェクトに含める必要があります。

オブジェクトのコレクションを使用し、個々のオブジェクト/エンティティを参照する計画があるシナリオでは、識別子を含める必要があります。ただし、そのような自然なキー/識別子DateTimeが人為的にそのニーズを満たすことができる場合があります。

さらに、DTOをオブジェクトの軽量コンテナーとして使用することもできます。これは、オブジェクト識別子自体をスキップまたは含めることができます。本当にこの選択はすべて、ビジネスのユースケースとニーズに本当に依存しています。

編集：オブジェクトを識別するには、識別子が必要です。その識別子は、サロゲートID、日時、GUIDなどです。基本的には、オブジェクトを他の人からユニークな方法で識別するものです。

私の答えをあなたの質問と同じくらい抽象的なものにしようとして、あなたは実際にあなた自身の質問に答えたと思います。

オブジェクトは、必要に応じて自身のIDを知っている必要があります。

必要のないオブジェクトは、ID（またはIDさえ持っている）を知っているべきではありません。

あなたが指摘したように、オブジェクトがそのIDを保持または知ることが不便または不必要な場合があります。しかし、オブジェクトがそのIDを認識している方が便利な場合もあります。用途に応じてオブジェクトをコーディングします。

IDを含めることはかなり一般的ですが、辞書を使用することも一般的です。つまり、対応するIDを知っているこのオブジェクトを簡単に取得できるが、オブジェクトが知らない方法で各オブジェクトがそのIDに関連付けられるデータ構造それ。

たとえば、2つのメソッドでAPIを作成している場合：

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

  製品のIDのリストをロードします。

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

  ID 452の製品をロードします。

その後、2番目のリクエストのJSONレスポンスでID 452を再送信する必要はありません。APIのユーザーはすでにIDを知っています。

これは主観的なものであり、デザインに依存すると思います。

ほとんどこれはアクティブなレコードから来ているデザインのように見えますが。アクティブなレコードでは、エンティティにデータベース操作を実行するメソッドがあるため、データベース識別子も知っている必要があります。

オブジェクトにこのデータを保存するデータマッパーでリポジトリなどの他のパタ​​ーンを使用すると、不必要になり、おそらく不適切になります。

たとえば、Personオブジェクトを取ります。家族内で一意である場合とそうでない場合があります。人口が増加するにつれて、より大きな名前は一意ではなくなり、ますます大規模なシステムのサロゲート識別子を見つけました。これらの例には、私の運転免許証、および社会保障番号が含まれます。私は生まれながらにIDを割り当てられていません。これらのIDはすべて申請する必要があります。

これらのほとんどは、普遍的ではないため、ソフトウェアの適切な主キー/ IDを作成しません。少なくとも特定のシステムの外側ではなく、明らかに社会保障局にとってSSNは一意であり、一貫性があります。私たちは一般にこの情報の提供者ではないので、あなたはそれらを提供するのidではなく、それらが表すデータ、例えばを呼ぶでしょうSSN。場合によっては、DriversLicense運転免許証が行うすべての情報を含む可能性のある完全な合成オブジェクトを含むこともあります。

したがって、すべての一般IDはシステム内の代理キーであり、メモリ参照で置き換えることができ、IDのみを含むことで、レコードの検索と永続化を容易にします。

an idは概念的なデータの一部ではないため、ドメインから取得したものではないため、（一般的に）オブジェクト内に属しているとは思えません。むしろ、一意のアイデンティティを表す他の方法を持たないオブジェクトを識別するという目的に保持する必要があります。これは、リポジトリ/コレクションで簡単に実行できます。

ソフトウェアでは、オブジェクトをリストとして表現したり、永続化したりする必要がある場合は、リポジトリ/コレクションオブジェクト、またはそれに関連付けられた他のオブジェクトから簡単に表現できます。データマッパーに渡す場合（別個の場合）、単に渡すことができます.update( id, obj )。

免責事項：私はまだエンティティ内にIDを含まないシステムを構築しようとしていないので、自分自身が間違っていることを証明するかもしれません。

GlenH7がコメントで指摘したように、多くの人々が当たり前のことと思っていることに挑戦するので、それは良い質問です。ただし、私の考えでは、IDを省略しても概念的に純粋に見えるかもしれませんが、システムのできるだけ多くの層にわたってIDをオブジェクトとともに保持することが実用的です。費用はほとんどかかりませんが、状況が崩れ始めたときに役立ちます。

個人が個人識別番号、運転免許証番号、またはあなたの場所で使用されている可能性のある他の識別子を知る必要がないように、エンティティはIDを知る必要がない場合があります。ほとんどの場合、それなしで確実に実行できます。ただし、念のために何らかの身分証明書を携帯することをお勧めします。

オブジェクトについても同じことが言えます。データアクセスレイヤーの複雑さに関係なく、オブジェクトは最終的に特定のデータベースエントリにマップされます。このエントリは、オブジェクトのIDによってのみ一意に識別できる場合があります。その場合、UIコード、ビジネスレイヤでの数値計算、リポジトリ自体、またはWebサービス全体の依存システムをデバッグしているかどうかに関係なく、この情報をいつでも利用できるようにしたいと思います。または、その問題についてエラーログを参照しているかどうか。

あなたの場合、データベースからデータを取得してウェブサービスにプッシュするだけなら、idを省くことは正しいことかもしれません。一般的なケースでそれを維持するよりも理にかなっているとは思わない。

リポジトリコンテキストでIDを知るだけでよい限り、オブジェクトにidを格納する必要はありません。

オブジェクトをそのコンテキスト外のコード、idでオブジェクトを要求しなかった（したがってまだ認識していない）コードにオブジェクトを渡すが、何らかの目的でIDが必要な場合（たとえば、リストに配置する場合）に状況は変わります後で別のコードによってリポジトリから要求されるIDの）。

その状況では、2つのオプションがあります。

• リポジトリコンテキストとidが必要な関数の間の関数チェーン全体に新しい関数引数 'id'を導入します

• オブジェクトにIDを含める

これらのほとんどの場合、オブジェクト内にidを保存する方がより良い解決策になります。また、予期しない場所でidが必要になったときにコードの変更を減らすことができます。また、デバッグ時に役立つことがあります。

だから私はそれをやるときにそれをやる。