Ich habe gehört, dass es ein Nein-Nein ist, @foreach in einer Ansicht zu haben. Das heißt, die Ansicht sollte keine Logik enthalten. Was ist die beste Vorgehensweise, wo sich die Logik für @foreach befinden sollte?
@foreach..
Ich habe gehört, dass es ein Nein-Nein ist, @foreach in einer Ansicht zu haben. Das heißt, die Ansicht sollte keine Logik enthalten. Was ist die beste Vorgehensweise, wo sich die Logik für @foreach befinden sollte?
@foreach..
Antworten:
Was ist die beste Vorgehensweise, wo sich die Logik für @foreach befinden sollte?
Nirgendwo, lass es einfach los. Sie können Editor- oder Anzeigevorlagen verwenden.
Also zum Beispiel:
@foreach (var item in Model.Foos)
{
<div>@item.Bar</div>
}
könnte durchaus durch eine Anzeigevorlage ersetzt werden:
@Html.DisplayFor(x => x.Foos)
und dann definieren Sie die entsprechende Anzeigevorlage (wenn Ihnen die Standardvorlage nicht gefällt ). Sie würden also eine wiederverwendbare Vorlage definieren ~/Views/Shared/DisplayTemplates/Foo.cshtml
, die vom Framework automatisch für jedes Element der Foos-Sammlung ( IEnumerable<Foo> Foos { get; set; }
) gerendert wird :
@model Foo
<div>@Model.Bar</div>
Offensichtlich gelten für Editor-Vorlagen genau dieselben Konventionen, die verwendet werden sollten, wenn Sie einige Eingabefelder anzeigen möchten, mit denen Sie das Ansichtsmodell bearbeiten können, anstatt es nur als schreibgeschützt anzuzeigen.
foreach
? Zumindest für eine Anzeigevorlage (obwohl dies ein durchaus akzeptabler Ansatz ist) muss eine neue Ansicht gerendert werden, die nicht kostenlos ist. Die meiste Zeit wirkt sich dies nicht merklich auf die Ladezeit Ihrer Website aus, aber wenn Sie dies genug tun, kann dies zu Leistungseinbußen führen. Ein foreach
bisschen HTML ist und bleibt praktisch augenblicklich. Wie ich schon sagte, es ist zwar keine große Sache, aber wenn überhaupt, gibt es ein Argument für die Verwendung foreach
.
Wenn Leute sagen, dass sie keine Logik in Ansichten einfügen, beziehen sie sich normalerweise auf Geschäftslogik und nicht auf Renderlogik. Meiner bescheidenen Meinung nach ist die Verwendung von @foreach in Ansichten vollkommen in Ordnung.
Ich verwende, @foreach
wenn ich eine Entität sende, die eine Liste von Entitäten enthält (z. B. um 2 Raster in einer Ansicht anzuzeigen).
Zum Beispiel, wenn ich als Modell die Entität Foo sende, die Foo1(List<Foo1>)
und enthältFoo2(List<Foo2>)
Ich kann auf die erste Liste verweisen mit:
@foreach (var item in Model.Foo.Foo1)
{
@Html.DisplayFor(modelItem=> item.fooName)
}
eine Antwort an @DarinDimitrov für einen Fall, in dem ich foreach in einer Rasiermesseransicht verwendet habe.
<li><label for="category">Category</label>
<select id="category">
<option value="0">All</option>
@foreach(Category c in Model.Categories)
{
<option title="@c.Description" value="@c.CategoryID">@c.Name</option>
}
</select>
</li>
Html.DropDownListFor
, der einfach den Titel berücksichtigt? Es ist trivial und verwandelt Ihre Ansichten nicht in Spaghetti-Code: stackoverflow.com/a/7938038/29407
optgroup
Elemente in der Auswahlliste zu rendern , da dies in den HtmlHelpers nicht unterstützt wird. Wenn Sie der Auswahlliste nur ein zusätzliches Element hinzufügen müssen, gibt es bessere Möglichkeiten, dies zu erreichen und dann den Helfer weiterhin zu verwenden.
Die Antwort funktioniert nicht, wenn die Überladung zum Anzeigen der Vorlage verwendet wird @Html.DisplayFor(x => x.Foos, "YourTemplateName)
.
Scheint so gestaltet zu sein, siehe diesen Fall . Auch die Ausnahme, die das Framework gibt (über den Typ war nicht wie erwartet), ist ziemlich irreführend und hat mich beim ersten Versuch getäuscht (danke @CodeCaster)
In diesem Fall müssen Sie verwenden@foreach
@foreach (var item in Model.Foos)
{
@Html.DisplayFor(x => item, "FooTemplate")
}
IEnumerable<T>
und ruft die Vorlage für den Typ T
für jedes Element auf.