关注「有鱼软考」，系统架构设计师备考干货持续更新。中间层是"业务逻辑"的承载层，本节接口+实现解耦、Spring IoC 注入、Facade 统一出口，以及 Domain-Service-Control 框架，都是案例与综合知识的重点。

一、本节一句话

中间层架构设计 = 业务组件（接口 + 实现 + Spring IoC/DI + Facade 统一出口）+ 工作流（WFMC 五接口）+ 实体表示（XML / 通用 DataSet / 有类型 DataSet）+ 业务容器（Domain-Service-Control）

二、知识框架

• ▪▪ ▪ ▪ • 业务逻辑组件设计：接口 + 实现类，Spring IoC/DI 注入 DAO，Facade 统一出口
• ▪▪ ▪ ▪ • 业务逻辑层工作流：WFMC 参考模型与 5 接口（过程定义/客户端/应用调用/协作/管理监视）
• ▪▪ ▪ ▪ • 业务逻辑层实体：特点 + 三种表示法（XML / 通用 DataSet / 有类型 DataSet）
• ▪▪ ▪ ▪ • 业务逻辑层框架：业务容器 + Domain Model - Service - Control

三、核心内容

业务逻辑组件设计

• ▪▪ ▪ ▪ • 组成 ：业务逻辑组件分为 接口 和 实现类 两部分。接口定义组件必须实现的方法（系统运行核心），通常按模块设计，每模块一个组件，每个组件以多个 DAO 为基础，对外提供业务逻辑服务。增加接口是为更好解耦，控制器面向接口编程、不与具体组件耦合。
• ▪▪ ▪ ▪ • 实现类 ：以 DAO 组件为基础，需接收容器注入的 DAO（提供 setter 方法）；将 DAO 接口实例作为属性（面向接口编程）。复杂逻辑访问多个对象数据时，在方法里调多个 DAO 接口，把具体实现委派给 DAO。
• ▪▪ ▪ ▪ • 配置（Spring IoC/DI） ：DAO 组件未被初始化，业务方法靠 Spring 的 反向控制/依赖注入（IoC/DI） 完成初始化。在 applicationContext.xml 中配置 FacadeManager 组件，采用继承事务代理模板、把原业务逻辑组件作为嵌套 bean；target 指定 TransactionProxyFactoryBean 的目标 bean。也可为组件指定单独事务代理属性、引用已存在的 bean。
• ▪▪ ▪ ▪ • 解耦效果 ：系统实现所有后台逻辑、向外提供统一 Facade 接口 ，前台 Web 层仅依赖此 Facade 接口。Web 层与业务层耦合非常松散，可在不同 Web 框架间方便切换，即使替换整个 Web 层也很容易。

业务逻辑层工作流设计

• ▪▪ ▪ ▪ • 工作流定义（WFMC） ：业务流程的全部或部分自动化，文档/信息/任务按过程规则流转，实现组织成员间协调以达业务整体目标。WFMC（1993 成立）推动标准化；它是反映业务流程的计算机化模型，解决多参与者按预定义规则传递文档/信息/任务以实现预期目标。
• ▪▪ ▪ ▪ 1. interface 1 过程定义导入/导出 ：转换格式与 API，支持过程定义互转；早期 WPDL，后发展为 XPDL。
• ▪▪ ▪ ▪ 2. interface 2 客户端应用程序 ：工作流机与任务表处理器交互，为用户资源组织任务，由任务表处理器推进任务项。
• ▪▪ ▪ ▪ 3. interface 3 应用程序调用 ：允许工作流机直接激活应用工具执行活动（多为后台服务，无用户接口）；需与终端交互时通常用 interface 2。
• ▪▪ ▪ ▪ 4. interface 4 工作流机协作 ：定义标准使不同厂商工作流系统无缝传递任务项；含 4 个协同工作模型。
• ▪▪ ▪ ▪ 5. interface 5 管理与监视 ：用户/角色管理、审查管理、资源控制、过程管理与状态处理。
• ▪▪ ▪ ▪ • 优点 ：将应用逻辑与过程逻辑分离，不改具体功能、只改过程模型即改系统功能，完成生产经营部分/全过程集成管理，有效把人、信息和应用工具组织在一起发挥最大效能。

业务逻辑层实体设计

• ▪▪ ▪ ▪ • 实体特点 ：提供对业务数据及相关功能状态的编程访问；可用复杂架构数据构建（常来自多相关表）；可作为业务过程 I/O 参数传递； 可序列化 以保持当前状态（本地磁盘/桌面库/消息队列）； 不直接访问数据库 （全由数据访问逻辑组件提供）； 不启动任何事务 （由使用它的应用/过程启动）。
• ▪▪ ▪ ▪ • 表示法一：XML （以 Product 实体为例，用 ProductID / ProductName / UnitPrice 等子元素描述业务数据）
• ▪▪ ▪ ▪ • 优点：①标准支持（W3C 标准）；②灵活性（表示层次与集合）；③互操作性（跨平台交换理想）。还可装入 DataSet 获数据绑定。
• ▪▪ ▪ ▪ • 表示法二：通用 DataSet ：DataSet 类实例（ADO System.Data），含多个 DataTable 表示库中取回信息。Product 实体对应一个 DataTable + UniqueConstraint（ProductID 主键）；Order 实体对应两个 DataTable（订单/订单明细）+ 各自 UniqueConstraint + Relation（关联二者）。
• ▪▪ ▪ ▪ • 优点（7 点）：①灵活性（含数据集合、表示复杂关系）；②序列化（层间传递支持）；③数据绑定（绑任意 UI 控件）；④排序与过滤（DataView）；⑤与 XML 互换；⑥开放式并发（配 DataAdapter 方便检查）；⑦可扩展性（改库架构后方法可创建修改后的 DataTable/DataRelation）。
• ▪▪ ▪ ▪ • 表示法三：有类型 DataSet ：包含严格类型方法/属性/类型定义的类，暴露数据与元数据。
• ▪▪ ▪ ▪ • 优点（3 点）：①代码易读（用有类型方法属性访问表列）；②有 IntelliSense；③编译时类型检查（无效表名/列名编译时发现而非运行）。

业务逻辑层框架

• ▪▪ ▪ ▪ • 业务容器 ：业务框架位于中间层，是实现功能的核心组件，采用容器形式便于开发、复用、管理。业务层以 业务容器（Business Container） 存在，大大降低与相邻层耦合——表示层只传业务参数，不需业务层多余干预，有效防止业务代码渗入表示层。
• ▪▪ ▪ ▪ • Domain Model - Service - Control
• ▪▪ ▪ ▪ 1. Domain Model = 领域层业务对象，仅含业务相关属性。
• ▪▪ ▪ ▪ 2. Service = 业务过程实现的组成部分，是应用程序不同功能单元，通过定义良好接口和契约联系；接口中立定义（不强制绑定特定实现）称为 松耦合 ——好处是灵活，且当各服务内部结构与实现渐变时仍能继续存在。
• ▪▪ ▪ ▪ 3. Control = 服务控制器，是服务间纽带，不同服务切换通过它实现；将服务实现与转向控制分离，提高灵活性与重用性。
• ▪▪ ▪ ▪ • 互动关系 ：①Service 运行依赖 Domain Model 状态，反之 Service 据业务规则改变 Domain Model 状态；②Control 据 Domain Model 状态与相关参数决定 Service 间执行顺序及关系。该互动吸取 MVC"控制与显示分离"优点演变而来，通过隔离服务与服务控制，使程序具备高度可重用性与灵活性。

四、关键概念速查表

五、易错·易混

六、章节速记

• ▪▪ ▪ ▪ • 三句话回顾 ：①业务组件接口+实现，Spring IoC 注入 DAO，Web 层仅依赖 Facade。②工作流 5 接口，逻辑与过程可分离。③D-S-C 三件套 + 业务容器组织业务、降耦。
• ▪▪ ▪ ▪ • 记忆口诀 ：接口实现配 Facade，工作流五口，DSC 三剑客，容器降耦合。
• ▪▪ ▪ ▪ • 关键词链 ：中间层 → 组件(接口/实现/IoC/Facade) → 工作流(WFMC 五接口) → 实体(XML/通用DataSet/有类型DataSet) → 框架(业务容器+Domain-Service-Control)
• ▪▪ ▪ ▪ • 自测三问 ：①业务实体能否直接访问 DB？②WFMC 哪 5 接口？③Control 作用？
• ▪▪ ▪ ▪ • 答案 ：①不能，由数据访问组件提供；②过程定义/客户端/应用调用/协作/管理监视；③服务控制器，据状态决定 Service 执行顺序。

如果本文帮你理清了中间层的"接口+Facade"与 D-S-C 框架，欢迎点赞、收藏、关注「有鱼软考」，下一节进入数据访问层设计。