エンティティのIDをコンストラクタ引数またはセッターメソッドを使用してですか？

Question

UserEntityなどのエンティティを持つ場合、idのプロパティはdbの主キーから派生します。setId()などのセッターメソッドを提供する必要がありますか？

に対するいくつかの引数：

• はデシベル
• 2つ（またはそれ以上）の他のUserEntitiesの可能性のある偶発上書きへの扉を開くUserEntitiesは同じidでいつでも存在する可能性がありますが、異なる性質。 （私は、DBから3種類のユーザーを引っ張って同じにそのid値を設定している場合）のために

いくつかの引数：私はidでUserEntityをインスタンス化する必要がない場合

• コンストラクタで（setterメソッドがあるので）、私は一時的/偽/新しいユーザ値を持つUserEntityオブジェクトのメソッドを使用することができます。

はセッターを提供（およびコンストラクタでidを強制していない）、またはコンストラクタでidを強制し、セッターを削除しますか？

Answer 1

エンティティのアイデンティティ値は、パーシスタンスレイヤーによって管理され、他のものによって設定できないことが理想的です。パーシスタンスレイヤーは、パーシスタンス時に新しいID値を割り当て、取得時に設定する必要があります。さらに、そのアイデンティティへのアクセスを必要とせずに、一時的な（永続的ではない）エンティティを使用できるようにする必要があります。アイデンティティ値の信頼できるソースがないため、アイデンティティをコンストラクタで設定できるようにすると、問題が発生する可能性があります。外部ソースからIDを割り当てることができる1つの例は、クライアントがIDとしてUUIDが新しく存在することをクライアントに要求する場合です。この例は考案されていますが。

Answer 2

@johnnietheblack、私はプライベートセッターとエンティティのIDへ公共ゲッターを作成することを好みます。 setterには（必要に応じて）検証が行われ、このIDをコンストラクタにのみ設定します。数値はゼロ値でインスタンス化され、ライフサイクルを追跡するのに役立ちます。

Eric Evansによるドメイン・ドリブン・デザインは、このアプリケーションのインフラストラクチャーの中で、Martin Fowlerによるエンタープライズ・アプリケーション・アーキテクチャーのパターンについて、モデル・ドメインについて語ります。私は彼らが相補人だと信じて、私はお勧めします。