代码之家 › 专栏 › 技术社区 › Greg

MVC视图:显示逻辑?

design-patterns language-agnostic model-view-controller

Greg · 技术社区 · 15 年前

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

视图中不允许有其他逻辑-例如 if (attr < 5) 只允许 if (valueLessThanFive)

这合理吗?大多数MVC框架允许在视图中使用任何逻辑,这可能导致业务逻辑进入视图。但是,只有这四种结构真的可以通过吗?

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

map(myList, [oddRowTemplate, evenRowTemplate])

但是如果你想让第一行和最后一行的样式不同呢?如果第三排在周二应该是紫色的,因为你的图形设计师是疯了?这些是特定于视图的(例如,如果我输出的数据与XML相同,我不会使用它们),因此似乎不属于模型或控制器。

综上所述:

2 回复 | 直到 15 年前

Vinay Sajip 15 年前

特伦斯·帕尔是个非常聪明的人,他的论文很值得称赞,但从实践的角度来看,我发现只是这些构造有些限制。

它是很难防止业务逻辑的蔓延,尤其是当您有能力做任何事情时,例如ASP.NET和JSP会给您提供。归根结底就是你如何花时间:

允许有限的附加功能(我不提倡“一切顺利”),并使用代码审查机制确保正确使用,或
限制到上面的四个构造,并花费更多的时间提供属性,如 valueLessThanFive (记住将其重命名为 valueLessThanSix 当业务需求更改时,或添加 valueMoreThanThree -举个例子有点开玩笑,但我想你会知道我在说什么)。

在实践中,我发现允许条件和循环构造是有益的,允许属性遍历,例如 attr[index].value 在模板表达式中。这使得表象逻辑得到有效的管理,同时只产生一个小的误用风险。

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

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

Timothy Walters 15 年前

在周二回答关于第三排紫色的问题:

原始的(或早期的)MVC模式中,“视图”是一个数据视图,模式中没有UI的概念。MVC模式的现代版本认为需要这种数据视图,这就是为什么我们有MVVM、MVP甚至 MV-poo .一旦您可以创建一个特定于UI视图的数据“视图”,就更容易解决许多问题。

在我们的例子中,我们的“模型”将获得额外的属性,例如样式或颜色(样式更好,因为它仍然允许视图定义该样式的表示方式)。控制器将采用原始的“模型”项目,并以这种额外的样式呈现给视图自定义的“模型”项目,在周二给第三行提供“MadDesignerSpecial”样式,视图使用该样式应用紫色。