在模板引擎中强制模型-视图严格分离.PDF

在模板引擎中强制模型-视图严格分离 被推荐为最佳论文 Terence Parr 旧金山大学 译注：部分翻译对照以及说明，参考文章最后的描述 Translated by: Richie 摘要： 每一位富有经验的web 应用开发者都主张：应当将业务逻辑和显示分离。然而几乎所有的模板引擎都允 许违背这一分离原则，这极大的推动了HTML 模板引擎的发展。这种情况主要是由于对分离缺乏形式的定义， 以及担心强制分离将消弱模板的生成能力（generational power ）。我将阐述严格的分离是非常有用的设计原则， 通过提供有效的模板引擎能够强制分离。我使用StringTemplate 引擎作为示例，用来建立jG 和其它的 商业网站，并解决一些重要的生成问题。 我的目的是使对模板引擎的研究形式化，因此提供一个通用的术语，这个术语是一种对模板生成能力分 类的方法，是对形式语言理论（formal language theory ）感兴趣的补充。类似Chomsky 的1..3 型语法分类， 我把限制性模板（restricted template ）分成三种类型，并且形式的定义分离，包括实现分离的规则。 因为这篇论文提供了一个清晰的模型-视图分离定义，模板引擎设计者也许不再盲目的主张强制分离概 念。此外，给出理论论点和经验证明，程序员不再有借口混杂（entangle ）模型和视图。 分类和主题描述： D.3.4 [程序语言] ：处理机-代码生成；D2.11 [软件工程] ：软件架构-面向领域的架构，模式，语言；D1.1 [编 程技术] ：应用（功能）编程 常规项： 语言 关键词： 模板引擎，Web应用，模型-视图-控制器 1. 简介 对动态生成web页面的需求，例如A上的图书显示页面，导致众多模板引擎的开发趋向于使web 应用开发简单化，提高扩展性，降低维护成本，允许编码和HTML 的开发并行。这种诱人的好处促进了模板 引擎的发展，这完全来自一个原则：将页面的业务逻辑声明（specification ）和数据处理声明，与页面怎样显 示这些信息的声明分离。通过隔离封装的声明，模板引擎促进了组件复用，可插拔的站点外观，通用组件的 单点变化（single-points-of-change ），良好的系统清晰度。 我曾经跟很多经验丰富的程序员讨论过分离原则，调查过很多通用的模板引擎，这些模板引擎使用各种 语言开发，包括Java 、C和Perl 。毫不意外，程序员赞成逻辑与显示分离是一种理想的原则。然而实际上，程 序员和引擎开发者不太原意强制分离，他们担心满足这个原则会损失生成能力，导致某个关键页面无法生成。 相反，他们鼓励而不是强制要求这一原则，给自己留一个退路，避免不完善的页面生成能力。 很不幸，在最终期限的压力下，只要可能，程序员会经常使用这个退路作为权宜之计，导致逻辑和显示 混杂。一个负责公司服务器数据模型的程序员告诉我，离最终期限他只有3天多时间，但如果强制他们的程序 员采用分离原则，修改那些受影响的多语言页面显示需要10天。为将来的维护考虑做正确的事情，他可能面 临被解雇的风险，或者他可以通过数据模型将新的HTML输出到页面，从而保住他的工作，将这种混乱留给 以后或者其它程序员。 另一种更普遍的情形是作为一个捷径，程序员将业务逻辑嵌入他们的模板中，避免更新数据模型。提供 完全图灵机式（Turing-Complete ）的模板编程语言，程序员就趋向于直接在模板中需要的地方添加业务逻辑， 而不是在数据模型中完成，从模型中解耦视图。例如几乎每个模板引擎的文档都有描述，如何根据用户权限 改变显示，不是简单的向模型询问用户是否特殊，而是在模板中编码逻辑来确定用户是否特殊。如果这个特 殊的定义改变了，可能系统中的每个模板都不得不修改，或者程序员可能忘了某个模板，给系统引入一个将 来随时可能出现的缺陷。通常这种捷径很快导致完全混杂的声明（entangled specification ）。 理想是否可能？就是说我们是否可以强制分离却又不消弱模板引擎的生成能力？限制性引擎导致一些 版权归原作者所有 WWW2004, May 17–20, 2004, New York, New York, USA. ACM 158113844X/04/0005. 页面无法