ドメインモデルを作成するとき、ほとんどの場合、データベース内の対応するテーブルの主キー列を表すエンティティの Id フィールドまたはプロパティがあります。私の質問は、ドメイン モデルとは関係のないこのキー プロパティがある場合 (つまり、これは単なるデータベースの問題です。Martin Fowler は意味のないキーと名付けることを好みます)、永続化レイヤーがドメインにリークしているのでしょうか? もしそうなら、どうすればそれを防ぐことができますか？
3 に答える
3
問題を別の見方で見てみましょう。主キーを非表示にすることで、チームがソリューションを開発しやすくなりますか、それともさらに困難になりますか?
エンティティに PK 値が「漏れる」ことを心配する必要はありません。ソフトウェアには、解決する必要のあるより大きな問題があるはずです。
于 2010-07-26T09:58:08.813 に答える
1
モデルでも意味のあるキーが識別されていることを確認してください。サロゲートを含めることはオプションですが、現実の世界でデータを理解する意味のあるキーを含めることははるかに重要です。
于 2010-07-26T20:48:34.607 に答える
1
「データベース システム - 完全な本」というタイトルの大きな本から。
キーは、エンティティ セット内のエンティティを一意に識別する属性または属性のセットです。キーを構成するすべての属性について、2 つのエンティティの値が一致することはありません。ただし、2 つのエンティティが属性のすべてではなく一部に同意することは許容されます。
-
私たちの経験[...]は、キーを見つけることや、属性のセットがキーを形成することを確認することは難しいと信じるようになるかもしれません. 実際には、問題は通常、はるかに単純です。一般的にデータベースによってモデル化される現実世界の状況では、人々はしばしばエンティティ セットのためにわざわざ行動します。たとえば、企業は通常、従業員 ID をすべての従業員に割り当てます。これらの ID は、一意の番号になるように慎重に選択されます。これらの ID の目的の 1 つは、同じ名前の従業員が複数いる場合でも、会社のデータベースで各従業員を他のすべての従業員と区別できるようにすることです。したがって、employee-ID 属性は、データベース内の従業員のキーとして使用できます。
挿入された人工 ID のみが異なるエンティティが重複 (冗長) データを導入する可能性があることは事実ですが、それらの使用は無意味ではありません。異なるドメイン エンティティを区別するための追加の方法は、私の意見では、ドメイン自体に干渉しません。
しかし、あなたの質問に対する答えについては：
永続化レイヤーがドメインにリークしていますか? もしそうなら、どうすればそれを防ぐことができますか？
あなたが本当に、本当にしたいのなら。エンティティ属性の組み合わせを使用して、エンティティ キーを定義できます。
それが役に立てば幸い。
于 2010-07-26T09:39:47.663 に答える