实例

    这一章的的组织方式和之前的模式有一些差别。我们先从一个例子来体会架构设计中分层的重要性。

    上图是一个业务处理系统的软件架构图。在上图中，我们把软件分为四个层次。这种层次结构类似于我们前面所谈的J2EE的分层。但是和J2EE不同的是，缺少了一个Web Server层，这是因为目前我们还没有任何对Web Server的需要。

    在资源层上，我们有三种资源：数据库、平台服务、UI。数据库是企业应用的基础，而这里的平台服务指的是操作系统系统或第三方软件提供的事务管理器的功能。值得注意的是，这里的事务管理器指的并不是数据库内部支持的事务，而是指不同的业务实体间事务处理，这对于企业应用有着很重要的意义。因为对于一个企业应用来说，常常需要处理跨模块、跨软件、甚至跨平台的会话(Session)，这时候，单纯的数据库支持的事务往往就难以胜任了。这方面的例子包括微软的MTS和Oracle的DBLink。当然，如果说，在你处理的系统中，可以使用数据库事务来处理大部分的会话的话，那就可以避免考虑这方面的设计了。除了典型的事务管理器，平台还能够提供其它的服务。对于大部分的企业应用来说，都是集成了多个的平台服务，平台服务对架构的设计至关重要。但是从分层的角度上考虑，上层的设计应该尽可能的和平台无关。和使用平台服务类似的，一般来说，企业应用都不会从头设计界面，大部分情况下都会使用现有的的UI资源。比如Window平台的MFC中的界面部分。因此，我们把被使用的UI资源也归到资源层这个层次上。

    资源层的上一层是集成层。集成层主要完成两项工作，第一项是使用资源层的平台服务，完成企业应用中的事务管理。有些事务处理机制已经提供了比较好封装机制，直接使用资源层的平台服务就可以了。但是对于大多数的应用来说，平台提供的服务往往是比较简单的，这时候集成层就派上大用场了。第二项是对上一层的对象提供持久性机制。可以说，这是一组起到过渡作用的对象。它实际上使用的是资源层的数据库功能，并为上一层的对象提供服务。这样，上一层的业务对象就不需要直接同数据库打交道。对于那些底层使用关系型数据库，编程中使用面向对象技术的系统来说，目前比较常见的处理持久性的做法是对象/关系映射(OR Mapping)。

    在这个层次上，我们可以做一些扩展，来分析层的作用。假设我们的系统需要处理多个数据库，而不同数据库之间的处理方式有一定的差异。这时候，层的作用就显示出来了。我们在集成层中支持对多个数据库的处理，但对集成层以上的层次提供统一的接口。对于业务层来说，它不知道，也不需要知道数据库的差别。目前我们自己开发了集成层中的持久类，但是随着功能的扩展，原有的类无法再支持新增加的功能了，新的解决方案是购买商用程序。为了尽可能的保持对业务层次的影响，我们仍然使用原有的接口，但是具体的实现已经不同了，新的代码是针对新的商业程序来实现的。而对业务层来说，最理想的状况是不需要任何的改变。当然现实中不太可能出现如此美好的情况，但可以肯定的一点是，引入层次比不引入层次要好的多。

    以上列举的两个例子都是很好的解决了耦合度的问题。关于分层中的耦合度的问题，我们在下面还会讨论。