10

LineItem (過度に使用されたショッピング カートの例から) があり、EditorTemplate を使用してレンダリングしたいとします。

親ビューから @Html.EditorFor(m => m.LineItems) を使用してレンダリングしても問題ありませんが (部分的またはその他)、混乱を招くのは、追加のデータを渡すための最良の方法です (データを持つ SelectList など)データベースから入ってくる) テンプレートに。

明らかに、これらの余分なアイテムを追加して LineItem モデルを汚染するべきではありません (ただし、ビューの観点からは必要です)。

ViewBag/ViewData トリックに頼る前に、強く型付けされた方法があるかどうかを確認しようとしています。

データを渡すために「LineItem」固有のビューモデルを作成しようとしましたが、MVC によって生成された名前を台無しにし、追加のレイヤーをコレクションに追加します (viewmodel の IEnumerable<> を EditorFor( ) 実際の LineItem の IEnumerable<> の代わりに呼び出します)

また、これは EditorTemplate の間違った使い方ですか? データベース テーブルからのオプションを持つドロップダウンを必要とする LineItem は、EditorTemplate には多すぎますか?

MVC 涅槃に向けて私を導いてください。答えを待っている間、他のアイデアを試してみます!

明確にするために：私が EditorTemplate の使用を検討している理由は、それが私に提供する自動コレクション処理のためです。そうしないと、[id] ビジネス全体が粘着的になりすぎます。

4

1 に答える 1

12

私は最近同じ問題に直面していて、この解決策を見つけました。

要約すると、元のコレクションと必要なサポート データをラップするカスタム ビュー モデルを作成する必要があります。次に、カスタム テンプレートを呼び出すビューで、HtmlHelper拡張メソッドのオーバーロードを使用して、サポート データをViewDataディクショナリに渡すことができます。カスタム テンプレートから frin を取得して使用できますViewData。

これは良い回避策であり、基本的にこれがビューモデルの目的であると思います。少なくとも、ビューに追加のデータを提供するためだけに元のクラスを拡張または派生するよりもはるかに優れています。

それがあなたのシナリオに当てはまるかどうか、または他の解決策が見つかった場合はお知らせください。

于 2011-08-12T15:14:50.773 に答える