接口程序开发攻略分析

      将软件分层意味着我们需要完成额外的工作——设计层次之间的接口。我们原来拥有的是一大块代码，现在则会有三处不同的代码块（业务逻辑、交互逻辑和标记），它们当中的每一块都需要和下一块交流。但是仔细考虑一下这样做是否的确造成了额外的工作？答案十有八九是否定的：分析一下我们现在仅有的那一层代码，会发现这些附加劳动早就完成了，只有逻辑层和标记层之间的交流还不是很明确，和其他剩余代码混在了一起。

     为什么要花心思在分层上呢？不管怎么说，在某种程度上，原来的那种所有代码都粘在一起的程序风格还是可以工作的。然而，有几个决定性的因素，它们将我们引向分层实现，而且随着系统规模逐步扩大，这些因素会一个比一个地变得更为重要。层次分离，让不同的工程师或工程师小组可以同时工作在系统的不同层次，而不用担心无意中影响了他人的工作。除了工作对象变成了不同的物理文件之外，这些小组也不再需要对其他层次有深入了解。标记层的工作人员不必理解数据是如何从数据存储中取出，并且传给模板系统的，他们只需要知道一旦这些数据交付给了他们，应该如何去使用这些数据。

     类似的，工作重点在交互层逻辑的工程师也不需要理解在取得一条数据的背后，系统逻辑层是如何运作的，而只需要知道用相应的函数调用就可以了。在这些例子中，工程师们惟一需要关注的元素就是自己所在层次的内容和所在层次与上层和下层的接口。那么，我们一直谈论的接口到底是什么呢？要知道当我们谈的是软件层次之间的接口时，所指的并不是Java中的面向对象概念上的接口。我们所说的接口，描述的是允许一个层次和另一个层次之间交换请求和响应的一组特性。对数据层与系统逻辑层而言，接口包括对原始数据的存储和抽取。对交互逻辑层与系统逻辑层，接口包括对特定类型数据源的修改。接口仅仅定义一个层次如何向另一个层次发出请求，要求它执行一个任务，而不管这个任务如何执行。

     我们的应用程序中最为顶端的层次是比较不一样的，因为标记层与表现层之间的接口已经由我们所采用的技术定义好了。标记层到样式表的链接使用的是链接标记符或者@import语句，通过它们获得class和id属性，以及样式表中的命名的标记符序列，根据这些可以应用特定的样式规则。为了保持良好的层次分离，在标记层中应尽量避免直接使用样式属性。本书并不包含前端工程的内容，但前端分层的原因和后端分层的原因是相同的——分离样式层与标记层，才能让不同团队可以独立地工作于项目的不同方面，并且开发人员可以进行层次内部修改，而不用担心影响相邻层次。

     交互逻辑层和标记层进行交流的典型方式是模板系统。在PHP和Smarty参考实现中，Smarty为PHP交互逻辑层提供若干功能。我们可以调用 Smarty的方法来将数据导出到模板（继而用于输出），也可以调用Smarty的方法来提供在模板内执行的展现函数，甚至还可以自己直接渲染模板。在某些情况下，我们需要的并不是直接得到模板的输出，然后将输出发送给终端用户。比如在发送电子邮件的时候，我们可以在模板系统中为它创建一个模板，导出所需要的数据和功能，把这个模板渲染到交互逻辑层的一个变量中，然后发送这封邮件。采用这种做法时，要注意到数据与控制不仅是单向流动的，控制在所有层次之间都可以双向传递。

     接口程序设计在Web应用程序体系结构中扮演着最主要的角色。接口程序会随着时间而演变，接口程序变动时，负责不同层次工作的团队必须得进行协商，但是这些更改应该只牵涉到小部分当前开发的内容。在不会无意中破坏其他部分的情况下，我们能在单个层次内做的越多，生产效率就越高，灵活性也越高。