StackOverflowなどの記事で、複数のエンティティから強く型付けされたビューにデータを集めるさまざまな方法について議論しています。これらはViewDataオブジェクトを使用しています。両方のエンティティを利用する。ViewDataを渡すことと新しいクラスを作成する
私には、あなたが新しいハイブリッドエンティティの一種を代表しているなら、あなたは新しいクラスを作り、そのように扱いたいと思うでしょう。しかし、あなたが作業しているエンティティの一部ではないがモデルに残っているもの（ドロップダウンリストや他のUIなど）のデータを渡す場合は、ビューデータを使用する理由がわかります要素。
私はさまざまな理由でどちらか一方を主張している人たちを見ています。
一度、型付きViewDataModelsを使用しました。私は、ViewData Dictionaryに物を入れ、Viewの魔法の文字列を扱う必要は一度もありませんでした。マジック・ストリングは汚れていて非常にエラーがあります。
私は、一般的にすべての私のコントローラのViewDataModelクラスを作成しているかどう、それは次のとおりです。
これらのすべて* ViewDataModelは、ビューにグローバルサイト構成データを渡すのに便利な、共通のViewDataModelクラスを拡張します。
私は、ViewDataModelに何を入れても構いません。必要な場合は、LINQ to SQLクラスや任意のメニュー構成クラスのいずれかであるかどうかを問わず、プロパティを作成して必要なときに入力します。
モデルオブジェクト以外の追加のプロパティを必要としない場合でも、ビューを再入力するよりも後でプロパティを追加する方が簡単です。かなり多くのViewDataModelクラスは1つのプロパティで構成されていますが、何もリファクタリングする必要なしにもっと追加できることがわかっているのは至福です。
ASP.NET MVVMは、ビューにモデルと迷惑（？）データを転送するトランスポータのViewDataModelクラスとしてASP.NET MVVMと考えることがよくあります。
返すモデル以上のものがない場合、ViewModelオブジェクトを作成することは、実際には良い習慣ではありません。サーバーのガーベッジ・コレクションのために、より多くのオブジェクトを作成するだけです。 ViewModelを使うのは良いことだと思いますが、それが必要なときだけです。しかし、私は魔法の弦を避けなければならないという事実に同意します。それは後で維持するのが難しい弱いコードを作ります。