Перемещение сложных условных операторов в код позади

Question

Мне просто интересно, если перемещение сложных операторов if else и результирующей разметки html в код позади нарушает какой-то закон 'MVC'?

Кажется, что это отличный вариант, когда сталкиваются со встроенными операторами if else, которые могут стать крайне нечитаемыми.

Answer 1

Не так уж и плохо иметь условности на ваш взгляд. Я бы оставил их в ASPX, а не в коде. Однако условное обозначение часто указывает на контролирующее поведение. Рассмотрим следующий код ASPX:

<%if (ViewData["something"] == "foo") {%>
     <%=Html.ActionLink("Save", "Save") %> 
<%}%>
<%if (ViewData["somethingElse"] == "bar") {%>
     <%=Html.ActionLink("Delete", "Delete") %> 
<%}%>

Этот набор условий представляет управляющее поведение, которое обрабатывается представлением, то есть не в том месте. Это поведение не может быть проверено модулем. Рассмотрим вместо этого:

<%foreach (var command in (IList<ICommand>)ViewData["commands"]) {%>
     <%=Html.ActionLink(command) %>
<%}%>

В этом примере ActionLink - это пользовательское расширение HtmlHelper, которое принимает наш собственный объект спецификации ICommand. Действие контроллера, которое отображает это представление, заполняет ViewData ["команды"] в зависимости от различных условий. Другими словами, контроллер выполняет управление. В модульных тестах для этого действия мы можем проверить, что правильный набор команд будет представлен при различных условиях.

Поначалу это может показаться хлопотным по сравнению с быстрым бросанием нескольких ПЧ в поле зрения. Вопрос, который вы должны задать себе: «Представляет ли этот IF контролирующее поведение, и хочу ли я убедиться, что он в какой-то момент не сломается?»

Answer 2

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

Когда я сталкиваюсь со сложной HTML-разметкой, которая относится только к проблемам просмотра, я обычно пишу метод расширения для класса HtmlHelper, чтобы скрыть сложность. Таким образом, у меня есть расширения, такие как Html.MoneyTextBox(), Html.OptionGroup() и Html.Pager<T>.

В других случаях, когда возникают сложные условия, обычно я что-то пропускал из контроллера. Например, все проблемы, связанные с видимостью элементов, доступными только для чтения или включенным, обычно связаны с тем, что может предоставить контроллер. В этом случае вместо передачи модели в представление я создаю модель представления, которая инкапсулирует модель и дополнительную информацию, которую может предоставить контроллер, чтобы упростить разметку HTML. Типичным примером модели представления является следующий:

public class CustomerInfo
{
  public Customer Customer { get; set; }
  public bool IsEditable { get; set; }  // e.g. based on current user/role
  public bool NeedFullAddress { get; set; }  // e.g. based on requested action 
  public bool IsEligibleForSomething { get; set; }  // e.g. based on business rule
} 

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

Answer 3

Codebehind является частью View - вам решать, хотите ли вы поместить вещи непосредственно в ASPX или в codebehind. MVC не означает, что вы должны кодировать все безобразно в ASPX:).

Answer 4

Я верю, что если это код рендеринга и он находится в «представлении», а не в контроллере, то размещение его в коде позади или в строке не будет иметь значения. Просто убедитесь, что вы не пишете этот фрагмент кода рендеринга в действиях Controllers (таким образом вы действительно нарушите шаблон MVC).