软考笔记--层次式架构之中间层架构设计

一.业务逻辑层组件设计

业务逻辑层组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个DAO（Data Access Object）组件作为基础，从而实现对外提供系统的业务逻辑服务。增加业务逻辑接口，是为了提供更好的解耦，控制器无须与具体的业务逻辑组件耦合，而是面向接口编程。

1.业务逻辑组件的实现类

业务逻辑组件以DAO组件为基础，必须接收Spring容器注入的DAO组件，因此必须为业务逻辑组件的实现类提供对应的setter方法。业务逻辑组件的实现类将DAO组件接口实例作为属性，而对于复杂的业务逻辑，可能需要访问多个对象的数据，那么只需在这个方法里调用多个DAO接口，将具体实现为派给DAO完成。

2.业务逻辑组件的配置

DAO组件初始化是由Spring的反向控制或者称为依赖注入机制完成的。为此，还需要在applicationContext.xml里面配置 FacadeManager组件。

定义FacadeManager组件时必须为其配置所需要的DAO组件，配置信息表示Base-Manager继承刚才配置的事物代理模板。并且由容器给Base-Manager注入DAO的组件，即BaseDAOHibernate。 而target则 是TransactionProxy FactoryBean 需要指定的属性， TransactionProxyFactoryBean 负责为某个bean实例生成代理，代理必须有个目标， target属性则 用于指定目标。

二.业务逻辑层工作流设计

工作流程定义为：业务流程的全部或者部分自动化，在此过程中文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。

用工作流的思想组织业务逻辑，优点是：将应用逻辑与过程逻辑分离，在不修改具体功能的情况下，通过修改过程模型改变系统功能，完成对生产经营部分过程或全过程的集成管理， 可有效地把人、信息和应用工具合理地组织在一起，发挥系统的最大效能。

三.业务逻辑层实体设计

业务逻辑层实体具有以下特点：业务逻辑层实体提供对业务数据及相关功能的状态编程访问。业务逻辑层实体可以使具体有复杂架构的数据来构件，这种数据通常来子数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分I/O参数传递。业务逻辑层实体是可序列化的，以保持它们当前的状态。业务层实体不直接访问数据库，全部数据库访问都是由相关联的数据访问逻辑组件提供的。业务逻辑层实体不启动任何类型的事物处理，事物处理由使用业务逻辑层实体的应用程序或业务过程来启动。

在应用程序中表示业务逻辑层实体的方法有很多(从以数据为中心的模型到更加面向对象的表示法),如XML、 通用DataSet、 有类型的 DataSet等。

例如，以下示例显示了如何将一个简单的业务逻辑层实体表示为XML。 该业务逻辑层实体包含一个产品。

<?xml version="1.0"?>

<Product xmlns="urn:aUniqueNamespace">

< ProductID>1</ProductID>

< ProductName >Chai</ProductName >

<QuantityPerUnit>10 boxes x 20 bags</QuantityPerUnit>

<UnitPrice>19.00</UnitPrice>

<UnitsInStock>35.9</UnitsInstock >

<Unitsonorder>1</UnitsOnOrder>

< ReorderLevel>15</ReorderLevel >

</Product >

将业务逻辑层实体表示为XML的方式有以下优点：

（1）标准支持。XML是W3C的标准数据表示格式。

（2）灵活性。XML可以表示信息的层次结构和集合。

（3）互操作性。在所有平台上，XML都是与外部各方及贸易伙伴交互信息的理想选择。

四.业务逻辑层框架

业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于功能的开发，代码重用和管理。业务层采用业务容器（Business Container）的方式存在于整个系统当中，采用此方式可以大大降低业务层和相邻各层的耦合，表示层代码只需要将业务参数传递给业务容器，而不需要业务层多余的干预。如此一来，可以有效防止业务层代码渗透到表示层。

在业务层容器中，业务逻辑是按照Domain Model-Service-Control思想来实现的。

(1)Domain Model是领域层业务对象，它仅仅包含业务相关的属性。

(2)Service 是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一是它的灵活性，二是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。

（3）Control控制服务器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。通过服务控制器控制服务切换可以将服务的实现和服务的转向控制分离，提高了服务实现的灵活性和重用性。

Domain Model—Service—Control的互动关系，是吸取了 Model—View—Control 的优点，在 “控制和显示的分离”的基础之上演变而来的，通过将服务和服务控制隔离，使程序具备高度的可重用性和灵活性。