ASP.NET MVC 视图中允许多少逻辑？

Question

我在查看ASP.NET MVC网站的示例时，发现许多示例中的视图都嵌入了逻辑代码，例如：

<% if (customerIsAllowed)
   { %>

   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>

<% }  else {%>

   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>
   <p>nnn</p>

<% } %>

虽然这似乎不对，因为在ASP 3.0中我们试图摆脱这种事情，但是我甚至听过一些播客说“在视图中加入一点逻辑是可以的”，因为MVC框架的其余部分正在处理在ASP 3.0中我们没有的结构。

是否有任何MVC约定规定了允许在视图中使用何种类型和多少逻辑？

- Edward Tanguay

Answer 1

这要取决于逻辑的原因。如果该逻辑是基于控制器传递给它的某些属性来选择备选呈现方式，那么可能可以接受。这允许您重复使用一些视图。与为每个自定义特权重新创建（和重复）整个视图相比，您可以传递一些数据，使得视图根据此特权进行自定义。

我认为这是理想化MVC和严格执行DRY（不要重复自己）之间的实用平衡。在某些情况下，如果难以同时实现两者，违反其中一个是更明智的。如果明显模型和基本视图是相同的情况下，在视图中加入一些逻辑以保持视图DRY是合理的。

- tvanfosson

---

同意。customerIsAllowed将基于模型中的某些领域逻辑进行填充，这使得此视图逻辑在我看来是可以的。 - Crescent Fresh

同意，逻辑的数量与关注点的分离无关。在视图中保持逻辑最小化是一个实际的问题。但是视图逻辑应该放在视图中。 - Haacked

同意。视图逻辑应该放在视图中。这就是为什么我不理解在MVC中使用Codebehind文件的激烈批评。我明白它可能被滥用，但有些简单的属性或条件逻辑有时比"<%"代码块更容易在codebehind中编写。 - Trevor de Koekkoek

我认为一个好的经验法则是从一个视图开始，但始终要预计， sooner or later 你的 if 语句和逻辑将在某个时候导致部分视图。根据我的经验，每个视图都以 If (something) else (something)... 开始，这是一个简单的 if 语句，不值得成为部分视图... 但是5个月后，它变成了 If (this or this but sometimes this also could be this) else (a bunch of other things).. - spaceman

有没有注意到一种讽刺，当人们提到DRY时，他们几乎总是需要在括号中扩展为“（不要重复自己）”。实质上，他们在解释规则时打破了这个规则。 - roryok

@roryok 我怪我的英语老师。我一直被教导第一次使用时要扩展除了普遍已知的缩写外的所有缩写。可悲的是，我认为DRY并不像它应该那样广为人知。 - tvanfosson

Answer 2

如果逻辑涉及视图格式，不会导致实体或数据的更改，则我认为可以在视图中使用。

- Matthew

Answer 3

42.

开玩笑的:-)

虽然没有固定答案，但是良好的关注点分离是一种普遍认可的最佳实践。这个问题的争论可能非常无休止，并且知道如何为您的特定项目正确地处理它需要经验和能够注意到“代码味道”或感觉不对的事情。

- Jesse

Answer 4

这里有另一种思考方式。展示逻辑放在视图中，业务处理逻辑放在控制器中，数据验证放在模型中。但是应该放在哪里的指导应该是指引而不是教条:)

- Barneytron

---

这是一个常见的误解。业务逻辑不应该放在控制器中，它是模型的一部分。控制器的职责是访问模型的适当部分，并使用找到的内容来决定显示哪个视图。 - Jack Ryan

我同意理想情况下控制器中不应该有业务逻辑（这是一个过载的术语）。但实际上，一小部分业务逻辑最终会出现在控制器中。这是我的两分钱 :) - barneytron

另一个误解是认为“业务逻辑”这个词有一个标准定义。因此，使用这个词是相当无用的，因为大多数人对其有不同的定义。 - dan-klasson

Answer 5

只要视图中的逻辑是用于表示（如果您不喜欢在标记文件中使用它，您可以将其放在代码后面文件中），那么就没问题。在您的示例中，代码/逻辑用于选择特定的视图部分，这很好。演示文稿允许具有逻辑，它不必仅仅是HTML。

- Andrei Rinea