Я слышал, что использовать @foreach внутри представления - это недопустимо. Это означает, что в представлении не должно быть никакой логики. Какова наилучшая практика того, где должна быть логика для @foreach?
@foreach..
Я слышал, что использовать @foreach внутри представления - это недопустимо. Это означает, что в представлении не должно быть никакой логики. Какова наилучшая практика того, где должна быть логика для @foreach?
@foreach..
Ответы:
Каков наилучший способ определения логики @foreach?
Некуда, просто избавься от этого. Вы можете использовать редактор или шаблоны отображения.
Так например:
@foreach (var item in Model.Foos)
{
<div>@item.Bar</div>
}
вполне может быть заменен шаблоном отображения:
@Html.DisplayFor(x => x.Foos)
а затем вы определите соответствующий шаблон отображения (если вам не нравится шаблон по умолчанию ). Таким образом, вы должны определить шаблон многократного использования, ~/Views/Shared/DisplayTemplates/Foo.cshtml
который будет автоматически отображаться фреймворком для каждого элемента коллекции Foos ( IEnumerable<Foo> Foos { get; set; }
):
@model Foo
<div>@Model.Bar</div>
Очевидно, что точно такие же соглашения применяются к шаблонам редакторов, которые следует использовать в случае, если вы хотите отобразить некоторые поля ввода, позволяющие редактировать модель представления, в отличие от простого отображения ее только для чтения.
foreach
? По крайней мере, шаблон отображения (в любом случае вполне приемлемый подход) требует визуализации нового представления, что не является бесплатным. В большинстве случаев это не окажет заметного влияния на время загрузки вашего сайта, но, сделав достаточно, это может привести к снижению производительности. foreach
Вокруг немного HTML и всегда будет практически мгновенно. Как я уже сказал, в любом случае это не имеет большого значения, но во всяком случае есть аргумент в пользу использования foreach
.
Когда люди говорят, что не помещайте логику в представления, они обычно имеют в виду бизнес-логику, а не логику рендеринга. По моему скромному мнению, использование @foreach в представлениях - это нормально.
Я использую, @foreach
когда отправляю объект, содержащий список объектов (например, для отображения 2 сеток в одном представлении)
Например, если я отправляю в качестве модели объект Foo, содержащий Foo1(List<Foo1>)
иFoo2(List<Foo2>)
Я могу сослаться на первый список с:
@foreach (var item in Model.Foo.Foo1)
{
@Html.DisplayFor(modelItem=> item.fooName)
}
ответ на @DarinDimitrov для случая, когда я использовал foreach в режиме бритвы.
<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
, который просто учитывает заголовок? Это тривиально и не превращает ваши взгляды в спагетти-код: stackoverflow.com/a/7938038/29407
optgroup
элементов в списке выбора, поскольку в HtmlHelpers это не поддерживается. Если вам просто нужно добавить дополнительный элемент в список выбора, есть лучшие способы добиться этого, а затем по-прежнему использовать помощник.
Ответ не сработает при использовании перегрузки для указания шаблона @Html.DisplayFor(x => x.Foos, "YourTemplateName)
.
Кажется, так устроено, см. Этот случай . Также исключение, которое дает фреймворк (о типе, отличном от ожидаемого), довольно вводит в заблуждение и обмануло меня с первой попытки (спасибо @CodeCaster)
В этом случае вы должны использовать@foreach
@foreach (var item in Model.Foos)
{
@Html.DisplayFor(x => item, "FooTemplate")
}
IEnumerable<T>
и вызовет шаблон для типа T
для каждого элемента.