Можно ли использовать для каждого цикла в представлении (альтернативы)?

Question

Я читал, что плохой практикой использовать любую логику в представлении при кодировании MVC. Но обычно я создал таблицы с помощью for each таким образом:

@ModelType IEnumerable(of ViewModel) 
<table>Prop1 
    <thead> 
     <tr> 
      <th> 
       @Html.DisplayNameFor(Function(model) model.Prop1) 
      </th> 
      <th> 
       @Html.DisplayNameFor(Function(model) model.Prop2) 
      </th> 
     </tr> 
    </thead> 
    <tbody> 
     @For Each item In Model 
      @<text> 
       <tr> 
        <td> 
         @Html.DisplayFor(Function(model) model.Prop1) 
        </td> 
        <td> 
         @Html.DisplayFor(Function(model) model.Prop2) 
        </td> 
       </tr> 
      </text> 
     Next 
    </tbody> 
</table> 

Есть ли альтернативный способ, или это немного логики в порядке?

Answer 1

Это зависит от причины логики. Если логика выбирает альтернативное представление, основанное на некотором свойстве, переданном ему контроллером, возможно, это нормально. Это позволяет вам повторно использовать повторное использование. Вместо того, чтобы воссоздать (и повторять) полное представление для каждой пользовательской привилегии, вы можете передать некоторые данные, которые позволяют настраивать представление на основе этой привилегии.

Я думаю, что это как прагматический баланс между идеализированным MVC и строгим соблюдением DRY (не повторяться). В некоторых ситуациях разумнее нарушать одно или другое, если вы не можете достичь обоих легко. В случае, когда четкость модели и базового представления одинаковы, нужно немного логично взглянуть на то, чтобы ваши взгляды DRY были разумными.

Логика, которую вы использовали, сбалансирована. И утверждение, которое вы передали, что лучше использовать логику в представлении правильно, но в случае бизнес-логики.

детали MVC есть.Короче говоря, они являются:

Модель = домен логика

Посмотреть = выход логики

Контроллер = входная логика

Но условные операторы могут быть использованы. Даже вы можете заполнить вас View, используя некоторые инструкции итерации. Ничего страшного в этом нет,

Answer 2

Я думаю, что вы, возможно, читали, что у вас не должно быть бизнес-логики в вашем представлении, которое может быть выполнено в вашем контроллере.

Вы должны выполнить операции, которые задают значения вашей модели в ваших контроллерах, а затем передавать их в ваше представление. Представление, как правило, не требует никакой дальнейшей обработки, кроме как для рендеринга вашей страницы, поэтому перемещение по спискам и другим объектам для их отображения на странице приемлемо и необходимо.

Если код, который у вас есть в вашем представлении, является универсальным и многоразовым в многоуровневых представлениях, я бы рекомендовал создать вспомогательный HTML-код, который вы можете повторно использовать, это сделает ваши представления намного чище.

Надеюсь, это поможет!

Answer 3

Пока вы привязываете представление к модели со стороны сервера, это правильный путь.
Другой альтернативой является привязка вида на стороне клиента, что, по моему мнению, является очень хорошей практикой. AngularJs - это библиотека зверя для этого. Вы просто извлекаете чистый html, и вы получаете модель как json и привязываете представление с помощью чистого javascript-объекта, используя угловые.
https://angularjs.org/

Answer 4

Я согласен с тем, что условные обозначения данных модели обзора должны находиться в пределах модели представления, и вы должны избегать ее в своих представлениях.

Однако простой для каждого цикла, где вы делаете только одну разметку для списка элементов, это вполне приемлемо.

Даже если вы использовали отдельные частичные представления или шаблоны отображения/редактора в какой-то момент, вам придется перебирать список элементов для генерации повторяющейся разметки.

Answer 5

В соответствии с тем, что я слышал и читал о хороших практиках в MVC для привязки ViewModel, это хорошая практика для его использования. Функция привязки ViewModel помогает поддерживать связь между моделью и контроллером. Вместо отображения его с использованием любого другого подхода, такого как ViewBag или ViewData, использование ViewModel Binding является более оптимизированным подходом. Я думаю, что плохая практика использует несколько запросов linq в представлении

Для примера.

@Model.Where(x=>x.Column1.Equals("1")).Select(y=>y.column2) 

Если у вас есть простой цикл Еогеаспа, зацикливание над моделью, что это хорошая практика, как вы не выполняете никакой Linq запросов на модели

Пожалуйста, поправьте меня, если я ошибаюсь