ドメインとEFに別々のモデルを使用する必要がありますか？

Question

シナリオ：レポート生成を処理するプログラムを作成しています。

私はEFモデルにマップされたデータベースにレポートを保存しています。非データベースフィールドがいくつかあります（つまり、一部のフィールドは、データベースにある他のフィールドに基づいて自動的に計算されます）。 DBに単独でマップする1つのクラスと、その情報を受け取り、さらに他の計算フィールドを持つ別のクラスを持つことは理にかなっていますか？ codefirstデータベースと対話するためのサンプルクラスすなわち

は、それが別のクラスを作るために理にかなって

public class Report{ 
    public int CategoryOneSeverity {get; set;} 
    public int CategoryTwoSeverity {get;set;} 
    public string Title {get;set;} 
} 

だろう、のような：

public class ReportModel{ 
    public int CategoryOneSeverity; 
    public int CategoryTwoSeverity; 
    public string Title; 

    public int RiskRating{ 
     get{ return CategoryOneSeverity + CategoryTwoSeverity; } 
    } 
}  

それともRiskRatingプロパティはEFにする必要がありますモデル。

Answer 1

はい、私は絶対にあなたのDBよりもあなたのドメインをモデル化するために異なるクラスを持つべきだと思います。アプリケーションが非常に些細な場合を除き、ドメインオブジェクトを直接マップする場合は、データ構造が必要なものに合わせて変更する必要があります。公開したくないものを公開する可能性があります。それを単一責任原則に違反していると考えてください。クラスにドメインオブジェクトを作成して直接マップすると、クラスには2つの理由があります。 1つはビジネス要件の変化に対応し、もう1つはデータストレージスキーマの変更に対応しています。

Answer 2

「それは意味が単独でDBにマップする一つのクラス、およびその情報を受け取り、さらに 他の計算フィールドを持つ 別のクラスを持つようになるだろう？」

はいそうです。私のエンティティクラスがHumanResourcesReportだった場合、通常、私は新しいクラスに "ViewModel"の後ろにHumanResourcesReportViewModelを作成します。

ViewModelsの使い方にはさまざまなバリエーションがありますが、用語についての賢明な議論ができますが、概念的には、エンティティを取り上げて、そのデータとレポートの処理に必要な追加情報を含む新しいクラスを作成します。この場合、レポートの生成はMVCモデルのビューと同じように行われるため、データを保持するクラスをViewModelと呼ぶのは面倒です。

Answer 3

DB Firstのコードファーストを使用していますか？

モデルには、データベースのフィールドにマップされていない自動計算フィールドを含めることができます。

また、アーキテクチャによって異なります。 DBを最初に使用している場合、EFモデルをリフレッシュすると、EFクラスが更新され、マップされたフィールドが失われます。 DB-Firstシナリオでは、EFモデルクラスを基底クラスとして使用し、それをレポートクラス用に継承する方法もあります。

public class ReportModel 
{ 
public int CategoryOneSeverity; 
public int CategoryTwoSeverity; 
public string Title; 
} 

public class ReportClass : ReportModel 
{ 
public int RiskRating 
{ 
get{ return CategoryOneSeverity + CategoryTwoSeverity; } 
} 
}