MVC视图:显示逻辑?

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

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

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

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

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

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

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

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

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