1

（DDDのように）エンティティクラスとして機能するクラスがあります。基本的には次のようになります。

public class Page
{
    protected String Name;
    protected String Description;
    protected Dictionary<int, IField> Fields = new Dictionary<int, IField>();

    protected Page SetName(String name)
    {
        this.Name = name;
        return this;
    }

    protected Page SetDescription(String description)
    {
        this.Description = description;
        return this;
    }

    public Page AddField(IField field)
    {
        this.Fields.add(xxx, Field); //xxx = just some id
        return this;
    }
}

今私の質問は、これは有効なエンティティクラスですか？

メソッドの連鎖を維持する必要があるので、それについてはあまり詳しく説明しないでください（間違っていると思われる場合でも）。

私の主な関心事は、エンティティクラスにゲッターやセッターなどのメソッドを含めることができるかどうかです。そして特にAddField？のような方法

このAddFieldメソッドは、タイプが。のオブジェクトを受け取りますIField。Pageそれをクラス内の辞書に保存します。それは骨材ですよね？

それはエンティティの状態を変更し、それを実際のエンティティクラスにしませんか？

それとも、それはそれがそうであるようにちょうどいいですか？

4

2 に答える 2

5

私の主な関心事は、エンティティクラスにゲッターやセッターなどのメソッドを含めることができるかどうかです。そして特にAddFieldのようなメソッド？

エンティティには、ゲッター、セッター、加算器、動作、およびビジネスルール（推奨）を含めることができます...基本的には何でもかまいません。

AddFieldメソッドは、タイプIFieldのオブジェクトを取ります。それをPageクラス内の辞書に保存します。それは骨材ですよね？

いいえ、それは集約ルートである可能性がありますが、必ずしもそうとは限りません。それはあなたの文脈とあなたがあなたの骨材をどのように設計するかに依存します。http://dddcommunity.org/library/vernon_2011を参照してください

それはエンティティの状態を変更し、それを実際のエンティティクラスにしませんか？

状態を変更するのはエンティティの性質そのものであるため、変更を追跡するためにIDを提供します。一方、値オブジェクトは、そのIDが重要ではないため、不変にすることができます。ほとんどの場合、値オブジェクトを変更せずに、新しいオブジェクトを作成するだけです。

DDDルートに行きたい場合は、ブルーブックまたは要約を読んで、アプローチの基本的な理解を得ることをお勧めします。DDDには独自の原則とデザインパターンがあります。パラダイム全体を採用しない場合、または少なくともその背後にある意図を理解しない場合、それらのいくつかをチェリーピッキングすることは必ずしも意味がありません。

于 2012-08-31T09:58:58.157 に答える
1

あなたのクラスは見栄えが良く、ほとんどの人がしているような男子生徒の間違いを犯していないと思います。辞書のゲッターがあります（したがって、辞書を適切にカプセル化して非表示にしています）。

ページをその名前で識別すると仮定しているので、それがエンティティに必要なIDになります。

骨材とは何かについて。Pageクラスを介して子（IField）へのアクセスを制御するため、Pageクラスは集約ルートのように見えます。

これ以上は言えません...元気そうです。

于 2012-08-31T09:15:57.407 に答える