MVC视图：显示逻辑？

Question

我一直在读这篇论文：Enforcing Strict Model-View Separation in Template Engines（PDF）。

它认为你在视图中只需要四个结构：

1. 属性参考
2. 基于属性的存在/不存在的条件模板包含
3. 递归模板参考
4. 模板应用程序到类似于lambda函数的多值属性 和LISP的地图运营商

视图中不允许使用其他逻辑 - 例如{}不允许使用if (attr < 5)，仅if (valueLessThanFive)

这合理吗？大多数MVC框架允许视图中的任何逻辑，这可能导致业务逻辑蔓延到视图中。但是真的有可能只用这四种结构来实现吗？

对于“斑马条纹”表，本文建议将模板列表映射到数据列表 - 例如：

map(myList, [oddRowTemplate, evenRowTemplate])

但是如果你想让第一行和最后一行的风格不同呢？如果因为你的平面设计师生气，第三排应该是周二的紫色怎么办？这些是视图特定的（例如，如果我输出的数据与XML相同，我就不会使用它们），所以似乎不属于模型或控制器。

总结：

• 您是否需要视图中上面列出的四种结构之上的逻辑？
  • 如果是这样，你如何限制业务逻辑的蔓延？
  • 如果没有，你会如何在星期二将第3排变成紫色？

Answer 1

特伦斯帕尔是一个非常聪明的人，他的论文有很多值得赞扬的，但从实际的角度来看，我发现使用只是这些结构有些限制。

很难阻止业务逻辑蔓延，特别是如果你有能力做任何事情，例如ASP.NET和JSP会给你。它归结为你如何度过你的时间：

1. 允许有限的附加功能（我不支持“任何事情发生”）并使用代码审查机制来确保正确使用，或
2. 限制为上述四种结构，并花费更多时间提供valueLessThanFive等属性（记住在业务需求发生变化时将其重命名为valueLessThanSix，或添加valueMoreThanThree - 它有点以滑稽为例，但我想你会知道我在做什么。）

在实践中，我发现允许条件和循环结构是有益的，因为允许在模板表达式中进行属性遍历，例如attr[index].value。这样可以有效地管理表现逻辑，同时只会产生很小的滥用风险。

允许更多功能（如任意方法调用）逐渐变得更加“危险”（在促进滥用方面）。它在某种程度上归结为您所在环境中的发展文化，开发过程以及团队中的技能和经验水平。

另一个因素是，在您的环境中，您是否可以在演示文稿和逻辑之间执行严格的工作分离，而不是让专业的非程序员设计师对模板中的高级构造感到困惑。在那种情况下，使用更受限制的模板功能可能会更好。

Answer 2

回答关于星期二第3行紫色的问题：

原始（或非常早期的一个）MVC模式的“视图”是数据视图，模式中没有UI的概念。 MVC模式的现代版本已经感觉到需要这种数据视图，这就是为什么我们有像MVVM，MVP，甚至MV-poo这样的东西。一旦您可以创建特定于UI视图的数据“视图”，就可以更轻松地解决许多问题。

在我们的例子中，我们的'model'将获得额外的属性，例如Style或Color（样式更好，因为它仍然允许视图定义该样式的表示方式）。控制器将采用原始“模型”项目并使用此额外样式向视图呈现自定义“模型”项目，在星期二为第3行提供“MadDesignerSpecial”样式，视图使用该样式应用紫色。