model-view-controller - MVC View : Display Logic?

Question

我一直在阅读这篇论文:Enforcing Strict Model-View Separation in Template Engines (PDF)。

它认为您只需要 View 中的四个构造:

属性引用

基于属性存在/不存在的条件模板包含

递归模板引用

模板应用到类似于 lambda 函数的多值属性
和 LISP 的 map 操作符

View 中不允许使用其他逻辑 - 例如 if (attr < 5)不允许，只有 if (valueLessThanFive)
这合理吗？大多数 MVC 框架允许 View 中的任何逻辑，这可能导致业务逻辑蔓延到 View 中。但是真的有可能只用这四种结构吗？

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

map(myList, [oddRowTemplate, evenRowTemplate])

但是如果你想让第一行和最后一行有不同的风格怎么办？如果星期二第三行应该是紫色的，因为你的平面设计师疯了怎么办？这些是特定于 View 的(例如，如果我输出与 XML 相同的数据，我不会使用它们)，因此似乎不属于模型或 Controller 。

总之:

您是否需要在 View 中上面列出的四个结构之上的逻辑？

如果是这样，您如何限制业务逻辑的潜入？

如果不是，你会如何在星期二让第三排变成紫色？

Answer 1

Terence Parr 是一个非常聪明的人，他的论文有很多值得称赞的地方，但从实践的角度来看，我发现仅使用这些结构有些局限性。

很难阻止业务逻辑的潜入，尤其是如果您有能力做任何事情，例如 ASP.NET 和 JSP 会给您。归结为你如何度过你的时间:

允许有限的附加功能(我不提倡“随心所欲”)并使用代码审查机制来确保正确使用，或

仅限于上述四个结构，并花更多时间提供诸如 valueLessThanFive 之类的属性。 (记得在业务需求更改时将其重命名为 valueLessThanSix，或者添加 valueMoreThanThree - 作为示例有点滑稽，但我想你会知道我在说什么)。

在实践中，我发现允许条件和循环结构是有益的，允许属性遍历(如 attr[index].value)也是有益的。在模板表达式中。这允许有效地管理表示逻辑，同时只产生很小的误用风险。

允许更多功能(例如任意方法调用)变得越来越“危险”(就促进误用而言)。在某种程度上，这取决于您所在环境中的开发文化、开发流程以及您团队的技能和经验水平。

另一个因素是，在您的环境中，您是否有能力在表示和逻辑之间执行严格的工作分离，就拥有专门的非程序员设计人员而言，他们会被模板中的高级构造所困扰。在这种情况下，使用更受限制的模板功能可能会更好。