1

私は、可能な限り柔軟である必要がある新しい大規模アプリケーションを設計しています。
私は主にDDDを使用して設計することを選択しました。
私の質問は、DTOオブジェクトをサービスレイヤーのDOオブジェクトに戻すことです。

すなわち：これはDBにマップされた私のドメインオブジェクトです（ORMを使用）

public class Cat  
{  
    int ID {get; set;}  
    string Name {get; set;}
    string BloodType {get; set;}
    string Color {get; set;}

    void Run(){...}
    void Purr() {...}
}

メソッドと一部のプロパティは、サーバーアクションにのみ必要です。
そのため、この猫の種類用に別のデータ転送オブジェクトを設計しました。

public class CatDTO 
{  
    int ID {get; set;}  
    string Name {get; set;}
}

途中で、DOをDTOに（またはその逆に）変換するオブジェクトマッパーを設定します。
クライアントが猫の名前を更新したいとき、彼はこのようなサービスを呼び出します

public void UpdateCat(CatDTO cat)  
{
   // What will happen here?
   Cat serverCat = Mapper.GetCat(CatDTO);

   CatDao.SaveOrUpdate(serverCat);
}

マッパーがDTOオブジェクトをDOに変換し直すとき、Catオブジェクトの欠落しているプロパティ（血液型など）を埋めるためにDBをヒットする必要があります。このアクションはばかげていると言う必要がありますが、空のプロパティを埋めることはありません。サーバー側の残りの部分は、欠落しているプロパティに依存しているため、Catオブジェクトを処理できません（DB内のデータを更新しようとしても、私のORMは血液型フィールドを空の文字列として更新します！）
この問題を検索しましたそして、ウェブ上で説明を見つけることができませんでした（または少なくとも私のように問題に悩まされている人）
私はそれを間違った方法で設計していますか？たぶん私は私のDDDで何かを逃しましたか？
ありがとう、パベル。

4

1 に答える 1

4

このユースケースの通常のワークフローは、マップされたドメインオブジェクトをIDで取得し、DTOで指定された更新を適用し、作業単位をコミットすることです。DAOと呼ばれるものは、通常、DDDではリポジトリと呼ばれます。コードは次のようになります。

public void UpdateCat(CatDTO catDto)  
{
   Cat cat = this.catRepository.Get(cat.ID);
   cat.Name = catDto.Name;
   this.catRepository.Commit();
}

このCommitステップはさまざまな方法で行うことができます。明示的な保存にすることも、作業単位をメソッドの外部でコミットすることもできますUpdateCat。このワークフローは、関連するすべてのシナリオにも適用されます。一般に、ドメインの動作には、適切なエンティティを取得し、そのエンティティで何らかの動作を呼び出してから、結果の変更をデータベースにコミットすることが含まれます。

また、DTOは既存のエンティティに直接マップして戻すべきではありません。代わりに、それらを既存のエンティティに適用される変更を表すものと考える方が適切であり、コードはこれを反映する必要があります。これは、既存のエンティティがリポジトリによって「所有」されており、リポジトリがDTOマッパーではなく再構成を担当しているためです。

于 2013-01-06T20:42:17.563 に答える