Słyszałem, że posiadanie @foreach wewnątrz widoku to nie-nie. Oznacza to, że widok nie powinien zawierać żadnej logiki. Jaka jest najlepsza praktyka dotycząca tego, gdzie powinna znajdować się logika @foreach?
@foreach..
asp.net-mvc
razor
Nate Pet
źródło
źródło
Odpowiedzi:
Nigdzie, po prostu się go pozbądź. Możesz użyć edytora lub szablonów wyświetlania.
Na przykład:
@foreach (var item in Model.Foos) { <div>@item.Bar</div> }
można by idealnie zastąpić szablonem wyświetlania:
@Html.DisplayFor(x => x.Foos)
a następnie zdefiniujesz odpowiedni szablon wyświetlania (jeśli nie podoba ci się domyślny ). Więc zdefiniowałbyś szablon wielokrotnego użytku,
~/Views/Shared/DisplayTemplates/Foo.cshtml
który będzie automatycznie renderowany przez framework dla każdego elementu kolekcji Foos (IEnumerable<Foo> Foos { get; set; }
):@model Foo <div>@Model.Bar</div>
Oczywiście dokładnie te same konwencje dotyczą szablonów edytorów, których należy używać w przypadku, gdy chcesz wyświetlić niektóre pola wejściowe umożliwiające edycję modelu widoku, w przeciwieństwie do wyświetlania go jako tylko do odczytu.
źródło
foreach
? Przynajmniej szablon wyświetlania (choć jest to całkowicie akceptowalne podejście, niezależnie od tego) wymaga renderowania nowego widoku, który nie jest bezpłatny. W większości przypadków nie wpłynie to zauważalnie na czas ładowania witryny, ale zrobione wystarczająco, może spowodować spadek wydajności. Odrobinaforeach
kodu HTML jest i zawsze będzie praktycznie natychmiastowa. Jak powiedziałem, nie jest to jednak wielka sprawa, ale jeśli już, jest argument za użyciemforeach
.Kiedy ludzie mówią, że nie umieszczaj logiki w widokach, zwykle odnoszą się do logiki biznesowej, a nie renderowania logiki. Moim skromnym zdaniem uważam, że używanie @foreach w widokach jest w porządku.
źródło
Używam,
@foreach
gdy wysyłam encję zawierającą listę jednostek (na przykład w celu wyświetlenia 2 siatek w 1 widoku)Na przykład, jeśli wysyłam jako model jednostkę Foo, która zawiera
Foo1(List<Foo1>)
iFoo2(List<Foo2>)
Mogę odnieść się do pierwszej listy z:
@foreach (var item in Model.Foo.Foo1) { @Html.DisplayFor(modelItem=> item.fooName) }
źródło
odpowiedź dla @DarinDimitrov na przypadek, w którym użyłem foreach w widoku brzytwy.
<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>
źródło
Html.DropDownListFor
, który po prostu uwzględni tytuł? To trywialne i nie zmienia twoich poglądów w kod spaghetti: stackoverflow.com/a/7938038/29407optgroup
elementów na liście wyboru, ponieważ nie ma tego wsparcia w HtmlHelpers. Jeśli potrzebujesz tylko dodać dodatkowy element do listy wyboru, są lepsze sposoby, aby to osiągnąć, a następnie nadal korzystać z pomocnika.Odpowiedź nie zadziała, gdy użyjesz przeciążenia do wskazania szablonu
@Html.DisplayFor(x => x.Foos, "YourTemplateName)
.Wydaje się być zaprojektowany w ten sposób, zobacz ten przypadek . Również wyjątek, który daje framework (o typie nie był zgodny z oczekiwaniami) jest dość mylący i oszukał mnie za pierwszym razem (dzięki @CodeCaster)
W takim przypadku musisz użyć
@foreach
@foreach (var item in Model.Foos) { @Html.DisplayFor(x => item, "FooTemplate") }
źródło
IEnumerable<T>
i wywoła szablon typuT
dla każdego elementu.