观点中的条件陈述是坏消息吗?

时间:2011-04-25 21:29:58

标签: asp.net-mvc asp.net-mvc-2 asp.net-mvc-3 razor

我需要快速的健全检查。我正在尝试设计我的观点,使它们干净,简洁,并且尽可能没有任何条件逻辑。但是,我很难摆脱所有条件语句。我想知道在视图中是否有一些条件语句是不可避免的?

例如:

@if (Model.UserCanEdit)
{
    <button type="button" id="Edit">Edit</button>
}

如果您的视图包含多个可以根据不同条件更改或显示/隐藏的元素,则选项不多。

那么我应该遵循哪些指导方针来确定在视图中允许条件逻辑的界限?在我的观点中有哪些方法可以减少我可能没有想到的条件逻辑?

提前致谢。

3 个答案:

答案 0 :(得分:10)

我不会说在视图中使用条件是完全不好的 - 毕竟视图的主要目的实际上是显示模型中的数据。 (有时需要条件语句来显示数据。)

  

然而 - 使用丰富的   条件可以进行维护   噩梦和最终的可读性。   重要的是要记住不要   包括在一定程度上的条件   成为业务逻辑,但允许   他们是为了达到他们的目的   “表达逻辑”。

可能的替代方案:

自定义HTML帮助程序:

如果你对使用条件不是很疯狂 - 你可以考虑使用Helpers来清理一些东西。有关详细信息,请查看Creating Custom HTML Helpers.

其他观点/部分观点:

此外,许多人会指出 - 使用条件将单个视图函数作为多个视图应该不是解决该问题的最佳方法。

答案 1 :(得分:3)

代码中的许多检查可能表示您尝试将一个视图视为两个单独的视图。

最好在控制器级别进行一次检查,然后使用适当定制的模型呈现不同的视图。这样,每个视图都保持“哑”状态,并且您没有向其传递更多信息。

直接回答你的问题 - 理论上,确保通过为每个这样的状态设置单独的视图来避免“全部”条件检查。但是,您可以拥有一个符合多个类似目的并具有条件的视图,同时保持可读代码并非不合理。

答案 2 :(得分:1)

在最佳情况下,尽量避免使用它们。它们开始很简单,但后来它们都变成了很多意大利面条代码。说你不可能总是可能而且几乎不可避免地要做到这一点。

通常您会分割视图或(具有多个部分视图),然后决定控制器上的if / else位。这可以确保您的ViewModel也保持不同。

-

根据经验,根据我的经验,我总是试图理解视图的业务视角而不是技术视角。有时您的两个视图可能看起来非常相似现在并且可能只需要一些if / else来区分彼此但是在业务方面它们是不同的并且很明显,每个视图都会有很多新要求将使其与其他视图完全不同。保持业务视角,您应该为两者创建单独的视图和视图模型。