ビューモデルを構築する最善の方法は何ですか？

Question

私はエンティティフレームワークでasp.net mvcを使用しており、DDDを学び始めています。私はアンケートを含むプロジェクトに取り組んでいます。ここに私のドメインモデルです：

public class Survey 
{ 
    public int? SurveyID { get; set; } 
    public string Name { get; set; } 
    public decimal MinAcceptanceScore { get; set; } 
    public int UserFailsCount { get; set; } 

    public IEnumerable<SurveyQuestion> Questions { get; set; } 
    public IEnumerable<Prize> Prizes { get; set; } 
    public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
} 

私は別のviewmodelsを作成しましたので、私は異なるビューのための調査の異なる部品が必要です。

public class ShortSurveyViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
    } 

    public class ShortSurveyWithPrizesViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

    public class SurveyEditViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public decimal MinAcceptanceScore { get; set; } 
     public int UserFailsCount { get; set; } 

     public IEnumerable<SurveyQuestion> Questions { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

私は私をしたい場合は、私のアーキテクチャを構築するための最良の方法だろう何適切なビューモデルに必要な情報を得るためにリポジトリを調査しますか？私が見

異なるsolusions：

1. リポジトリがSurveyServiceへのIQueryableを返すことができ、サービスがapproprieteビューモデルを返すことができますが、私はビューモデルがUIで作成する必要があると思うので、これを行うことは権利であることをためらいますサービス層ではありません。

2. 私のドメイン層に3つの適切なクラスを作成します。しかし、今やドメインは表現に依存し、新しいビューごとに新しいドメインクラスを作成する必要があります。

3. 完全なドメインオブジェクトを取得し、特定のビューに必要なプロパティだけをマップします。これは私の例ではうまくいかない質問は一つの表現でしか必要でなく、重いコレクションかもしれません。あなたの主な関心事は、ビューモデルに必要なデータの量対データモデルから取得したデータの量であることを考えると

Answer 1

ドメイン駆動設計：

• あなたは、集約ルートを返すリポジトリを持っている必要があります - あなたのケースでは、親Survey
• なしでは存在できないSurveyとすべての関係は、このリポジトリは、常に全体Surveyクラスをロードし、に応じてますあなたの要件はちょうどいくつかの関係（本当に独断的なDDDは常に全体の集計をロードしますが、それはステートレスWebの良いアプローチではありません）。
• アプリケーション層（コントローラ）はSurveyと選択されたリレーションをリポジトリに要求し、ビューモデルを塗りつぶします。

オニオンアーキテクチャ：

• あなたはIQueryable<Survey>を露出させ、いくつかのリポジトリを作成します - さらに悪いことに、あなたは、あなたがリポジトリと建物LINQのツーエンティティを呼び出して、いくつかのサービスを作成しますCRUDインターフェース
• で一般的なリポジトリを使用しますあなたのDTOに投影してアプリケーション層（コントローラ）に戻す
• 今何ですか？あなたは意志
  • ：あなたは

  シンプルなアーキテクチャ...これらのDTOを直接使用したり、いくつかのUI関連の属性など何か問題が明らかに存在して、あなたのビューモデルとして使用されるオブジェクトの別のセットを使用しますか、使用はあなたがビューモデルを埋めるためにあなたのコントローラに直接LINQのツーエンティティ予測を行います

• リポジトリとしてお使いのコントローラに直接IDbSet<Survey>を注入し

THER eは最善の方法ではありません。それは常にあなたの目標とあなたの期待についてです。小規模なアプリケーションでは、問題なくシンプルなアーキテクチャで暮らすことができます。

ドメイン駆動型設計はより複雑です。 DDDの主なコンセプトは、ドメインエンティティ、バリューオブジェクト、およびその構成です。ドメインエンティティは、これらのデータで実行されるデータとロジックをカプセル化します。 DDDは部分的なデータやDTOでは機能しません。ドメインエンティティに間違っているロジックがないとき（貧血モデルと呼ばれます）。 DDDのサービスは、アプリケーション層とリポジトリの間のメディエータではありません。これは、単一ドメインエンティティに関連しないビジネスロジックを処理するために使用されます（したがって、ドメインエンティティにカプセル化することはできません）。リポジトリは、ストレージから集約を実体化し、ストレージに保存するために必要なインフラストラクチャコードです。アプリケーションロジック（コントローラ）は、ドメインエンティティ、サービス、およびインフラストラクチャコードと対話できます。

私はタマネギの建築が嫌いです。

Answer 2

、私はあなたのための適切なアプローチがでビューを構築するだろうと言うでしょうデータベースとそれぞれのデータモデル。

これにより、任意の1回のトリップでデータベースから活用されるデータの量を減らすことができます。

データモデルはほとんどView Modelを模倣しますが、問題はありませんが、2つの異なる目的を果たします。ビューモデルは、ビューをバインドするためのものです。データモデルは、データの取得および保存方法を認識しています。これらのビューを作成すると、最適な方法でデータを取得できますが、必要に応じてそれらのモデルにカスタム保存ロジックを保存して書き込み可能にすることができます。