Question

我只是想知道，如果将复杂的if if语句和后面的html标记移动到后面的代码中会违反某些“MVC”法则吗？

当遇到内联if if语句时，它似乎是一个很好的选择，可能变得非常难以理解。

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进入视图相比，这似乎很麻烦。你必须问自己的问题是，“这个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

我相信只要它是一个渲染代码并且它位于一个不在控制器中的“视图”中，那么将它置于后面或内联的代码中并不重要。只要确保你没有在Controllers动作中编写这段渲染代码（这样你就会违反MVC模式）。

Answer 4

代码隐藏是View的一部分 - 如果你想直接或在代码隐藏中把东西放在ASPX中，这取决于你。 MVC并不意味着你必须在ASPX中编写所有丑陋的东西：）。

将复杂的条件语句移动到代码后面

4 个答案: