9

本当に簡単な質問。

現在、asp.net MVC とエンティティ フレームワークを使用してサイトを構築しています。エンティティまたはエンティティのリストを返すリポジトリがいくつかあります。私のページの大部分で、さまざまな関連テーブルからデータを取得する必要があることがわかりました。クエリで「include」を使用して関連エンティティをロードする限り、これは問題ありませんが、これは良い方法ですか?

必要な情報だけを含むカスタムビューモデルオブジェクトを作成する方が良いでしょうか、それとも、ビューに必要なものを表示するためだけに、おそらく5〜6テーブルの深さのオブジェクトグラフをプルすることに「問題」はありませんか? ?

この質問があまり意味をなさない場合はお詫び申し上げます。ここでモデルをどのように使用すべきかを根本的に誤解している可能性があります:)

ありがとう

4

2 に答える 2

3

ビューが次のようなことを開始した場合

<% foreach (var order in Model.Orders.Any(x => x.Products.Any(p => p.Category == "xx")) %>

次に、間違いなくViewModelが必要です。あなたは一緒に行くことができます

ViewData["flattened_orders"]

あなたが魔法の弦を好むなら、私はそうは思わない.

次に、エンティティに必要なプレゼンテーション属性の問題があります。次に、モデル バインダーが機能するように、それらのすべてのプロパティを公開する必要があります...次に、国のリストなどの追加のプレゼンテーションのみの情報が必要です...

そのため、単純なアプリケーションの場合、ViewModel をスキップできます。ただし、単純なアプリケーションの場合は、とにかく Response.Write と手動 SQL を実行できます ;-)

私は実際、同様の問題に関するこの投稿が好きです。そこに示されているアプローチは、最初は「アカデミック」すぎるように見えるかもしれませんが、実際のプロジェクトからのものであり、ASP.NET MVC をやればやるほど好きになり、それに近づきます。

于 2009-09-30T20:04:13.553 に答える
2

ビューのレンダリング コードとコントローラーのポスト コードを確認することをお勧めします。あなたが取っているアプローチによって、それらは過度に複雑になっていますか? そうでない場合は、おそらく現状のままで問題ありません。カスタム ビュー モデルを導入することでビューとコントローラーのコードが大幅に簡素化される場合は、ビュー モデルの作成を検討してください。カスタム ビュー モデルは本質的に、現時点ではおそらく別の場所で処理されている複雑さの一部を抽象化します。

于 2009-09-30T15:47:09.097 に答える