簡単な答えは「はい」です。ラムダ メソッドに引数として渡すモデルが必要です。ビューにモデルがなく、DisplayFor または EditorFor を呼び出すと、"テンプレートは、フィールド アクセス、プロパティ アクセス、単一次元配列インデックス、または単一パラメーターのカスタム インデクサー式でのみ使用できます" というエラー メッセージが表示されます。
したがって、DisplayFor を使用するにはモデルが必要ですが、実際に使用する必要はありません。たとえば、次のようにします。
Html.EditorFor(m => i)
その場合、Html 名と ID は両方とも「i」になります。
ただし、注意すべき考慮事項がいくつかあります。たとえば、Shared/Display Templates または Editor Templates フォルダーに、SubModel の厳密に型指定された部分ビューを作成することができます。その場合、DisplayFor で foreach を使用できます。
EditorFor を使用していて、投稿されたフィールドをモデルに再度バインドする場合は、次を使用する必要があります。
for (i = 0; ...)
Foreach ではなく、Html フォーム フィールドが Subs[1].Name などのバインド可能な名前になるようにします。foreach を使用すると、すべての入力が同じ名前と ID になります。たとえば、次のようになります。
id="s_Name" name="s.Name"
一方、for ループを使用すると、次のようになります。
id="SubModels_0__Name" name="SubModels[0].Name"
for ループは正当な html (一意の ID) を生成し、サーバー上のリストに再バインドできます。
明確にするために: EditorFor または DisplayFor を使用する場合、注意すべき点が 2 つあります。まず、渡す式によって、Html 要素に使用されるフィールド名が決まります。式がモデルに関連する場合、上の例に示すように、名前はモデルに由来します。したがって、モデルのサブクラスにバインドすると、次のようになります。
Html.DisplayFor(m => m.Submodel.Name)
Html フィールド名は「Submodel.Name」になり、ポストバック時に同じ階層に再バインドされます (オーバーロードされたメソッドの 1 つを使用して自分で名前を設定することもできます)。
2 つ目の側面は、式が型指定されている (つまり、CLR 型またはカスタム型の 1 つに解決される) ことです。その型をレンダリングするために、MVC はモデルが一致するテンプレートを探します。現在の View フォルダー、次に Shared フォルダーで始まるパス階層を使用してテンプレートを検索し、カスタム テンプレートが見つからない場合は内部テンプレートにフォールバックします。
したがって、必要なレンダリングとポストバック バインディングを実現するには、これらの両方を考慮する必要があります。ただし、データの表示のみに関心がある場合は、Html フィールド名がモデルと一致するかどうかを心配する必要はありません。任意の名前を使用するか、まったく使用せず、MVC にそれらを生成させることができます。ただし、Html id は一意である必要があり、上記の foreach の例のように、同じ id になる可能性があることにも注意してください。現在のブラウザでは問題はないようですが、Javascript を使用して ID で選択する場合は興味深いでしょう。