面向服务的开放式平台架构(9)
时间:2017-02-18 09:52 来源:毕业论文 作者:毕业论文 点击:次
发布和服务组合。一个典型的应用是系统的表示层，表示层直接封装了服务层所发布 的服务，并向用户提供了友好的交互接口。 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时，首先需要定位问题，以确定具体的修改点是位于业务逻 辑层还是数据访问层，之后进行相应的修改。由于业务逻辑层和数据访问层之内没有 更加具体的划分，因此对一个业务功能的修改可能会导致同一层依赖这一功能的调用 方也需要进行一定的修改，更进一步地，如果业务功能的修改会导致层之间接口的变 化，这一改变将会影响多个层。如果业务功能的改变需要导致用户界面的改变，需要 同时修改表示层。 (责任编辑：qin) |