あらゆる種類のデータを必要とするビューごとに ViewModel を作成することをお勧めします。
この場合、次を作成します。
public class SalesAllViewModel
{
IEnumerable<OrderProductVariant> _orderProductVariant;
public SalesAllViewModel(IEnumerable<OrderProductVariant> orderProductVariant)
{
this._orderProductVariant = orderProductVariant;
}
}
ビューに渡された値に基づくロジックが必要な場合は、モデルでそれらを変更します。
public int SumOfSomethingInOrderProductVariant(int id)
{
return this._orderProductVariant
.Where(opv.ID == id)
.Sum(opv => opv.IntValue);
}
これは、ビュー内のすべてのデータでロジックが一貫していることを意味します。ビューで何らかのロジックを使用して同じ値を表示する複数の領域がある場合、忘れがちで、他の場所に値をコピーして貼り付ける (yeeesh) 必要があります。
ViewBag または ViewData の使用は、コントローラーまたはビューで実際に何が起こっているかを誰も知ることができず、すべての魔法が View(Bag/Data) に隠されているため、通常は眉をひそめられます。
更新 1
Model–view–controller の詳細をお読みください。
ViewModel (MVC の技術的な説明では単なるモデル) は、データ アクセスとは何の関係もありません。これは、Entity Framework、Oracle、XML、またはその他のデータ ストレージ/検索テクノロジとは何の関係もない単なるPOCOです。ViewModel の背後にある目標の 1 つは、データ ソースからビューを切り離すことです。
さらに混乱しているのは、コードファーストのアプローチです。よく構築されたデータベースなしで???
この質問は ViewModels とは関係ありません。また、それは主観的な質問であるため、それに答える正当な理由はありません。
私が使用しているデータベースでは、すべての Include("Order") は必要ないようです
EDMX ファイルについて言及したので、Entity Framework について話していると推測できます。Entity Framework の使い方はあなた次第です。パフォーマンス上の理由でインクルードする必要がある場合はインクルードしてください。提供されるデータが必要ない場合は、使用しないでください。いずれにせよ、MVC での ViewModel の使用方法には関係ありません。