发布和服务组合。一个典型的应用是系统的表示层，表示层直接封装了服务层所发布
的服务，并向用户提供了友好的交互接口。
4.2.4. 表示层
表示层提供了基于 B/S的界面呈现，同时也文护了开放平台授权机制以及开放平
台 API。表示层仅依赖于服务层，而且仅包含表示逻辑，因此相对轻量。由于表示层
不包含业务逻辑，因此可以很好地支持反向代理，尽可能减小系统的整体负载。
4.3.  对比
本节将对比面向服务的开放式平台架构与经典的三层架构，重点比较架构的可扩
展性和可文护性。
三层架构属于分层架构的一种，它将整个应用程序自上而下划分成表示层（UI）、
业务逻辑层（BLL）和数据访问层（DAL）。架构如图4-10所示。
 
图4-10：三层架构
三层架构中表示层即为用户界面，业务逻辑层包含了应用程序中的所有业务逻
辑，即对于数据的业务操作。数据访问层直接操作数据，负责数据的添加、修改、删
除、查找（CRUD）操作。
作为一种分层架构，三层架构具备了“高内聚，低耦合”的特点，一个层内的改   
变在不影响层之间接口的情形下不会影响其他的层。同时，由于层与层之间的依赖是
向下的，因此改变上层对于下层不会有任何影响，在层与层之间有良好接口定义的情
形下，对任何层的改变都不会对系统中其它层产生影响。这样的设计可以使得开发人
员更容易地关注某一层，也可以相对容易地用新实现的层去替换已有层。
但三层架构应对业务系统的扩展时会显示出它的级联修改的弊端。如果业务变
化，需要添加新的业务功能时，首先需要改变业务逻辑层，而在三层架构中业务逻辑
层的持久化支持是由数据访问层提供的，为了保证业务功能添加后系统不出现架构漂
移，必须同时修改数据访问层，添加相应的持久化代码，最后如果业务功能需要用户
交互过程的话，还需要修改表示层，添加与业务功能对应的界面呈现。因此，一个业
务功能导致了系统中所有三个层的改变，间接增加了开发成本，也没有从层之间的松
散耦合中获得收益。如图4-11所示。
 
图4-11：在三层架构约束下添加业务功能
而在面向服务的开放式平台架构中添加新的业务功能时，只需要添加新的内核扩
展，并按需要添加对应的内核契约，即可完成业务逻辑的变化。这一变化只包含添加
操作，而不包含修改操作，从而尽可能减少对现有代码的影响。之后，可以根据需要
添加对应的策略并将公开接口发布为 Web Service，并修改表示层。与三层架构相比，
面向服务的开放式平台架构可以更好地支持对业务功能的添加。如图4-12所示。     
 
图4-12：在面向服务的开放式平台架构约束下添加业务功能
三层架构在应对业务功能的修改时同样存在级联修改的问题。当业务功能需要发
生变化，或需要修复 Bug时，首先需要定位问题，以确定具体的修改点是位于业务逻
辑层还是数据访问层，之后进行相应的修改。由于业务逻辑层和数据访问层之内没有
更加具体的划分，因此对一个业务功能的修改可能会导致同一层依赖这一功能的调用
方也需要进行一定的修改，更进一步地，如果业务功能的修改会导致层之间接口的变
化，这一改变将会影响多个层。如果业务功能的改变需要导致用户界面的改变，需要
同时修改表示层。 面向服务的开放式平台架构(9):http://www.youerw.com/jisuanji/lunwen_3091.html