当前位置：首页 > news >正文

系统架构设计师备考第53天——业务逻辑层设计

news 2025/10/25 6:42:59

组件结构
- 接口与实现分离：业务逻辑组件分为接口（定义服务方法）和实现类（具体逻辑），面向接口编程降低耦合。
- 模块化设计：按系统模块划分业务逻辑组件（如订单模块、用户模块），每个组件依赖多个DAO（数据访问对象）完成数据操作。
- 依赖注入：通过Spring IoC容器注入DAO组件，实现类只需声明DAO接口的Setter方法，由容器管理依赖。
事务管理
- 配置方式：在applicationContext.xml中配置事务代理（如TransactionProxyFactoryBean），为目标业务组件添加事务特性。
- 嵌套Bean：业务逻辑组件作为嵌套Bean配置，避免直接调用无事务特性的组件。
解耦价值
- Facade模式：提供统一的Facade接口供表现层调用，使Web层与业务层松散耦合，便于切换Web框架。

典型考题：
Q：为何业务逻辑组件需依赖DAO接口而非具体实现？
A：通过依赖注入解耦，便于替换数据访问实现（如从Hibernate切换至MyBatis），提升扩展性。

定义（WFMC标准）
- 工作流是业务流程的自动化，通过规则驱动文档、信息或任务流转，实现跨部门协作目标。
- 参考模型：包含五大接口：
  - Interface 1：过程定义导入/导出（支持XPDL标准）。
  - Interface 2：客户端应用接口（任务表处理器管理用户任务）。
  - Interface 3：应用调用接口（激活后台服务工具）。
  - Interface 4：工作流机协作接口（跨系统任务传递）。
  - Interface 5：管理监控接口（用户/角色/资源管理）。
优势
- 过程逻辑与业务逻辑分离：修改流程模型即可调整系统功能，无需改动具体业务代码。
- 提升协同效率：整合人、信息与应用工具，支持任务中断恢复与状态管理。

考点：工作流通过过程逻辑抽象解决传统业务代码与流程强耦合问题。

核心特性
- 数据封装：封装业务数据及相关状态，数据可能来自多张关联表。
- 无直接数据库访问：由数据访问逻辑组件提供数据。
- 可序列化：支持状态持久化（如存储至消息队列或本地缓存）。
实体表示方法对比

表示形式	优点	适用场景
XML	标准格式、跨平台互操作性强、支持层次化数据结构	外部系统交互、数据交换
通用DataSet	灵活表示数据关系、支持数据绑定/排序/过滤、与XML互转、开放式并发	ASP.NET/WinForm数据绑定
有类型DataSet	编译时类型检查、代码可读性高（IntelliSense支持）、避免运行时名称错误	强类型数据访问场景

示例：

<Product xmlns="urn:aUniqueNamespace"><ProductID>1</ProductID><ProductName>Chai</ProductName><UnitPrice>18.00</UnitPrice>
</Product>

考题：
Q：业务逻辑层实体为何不直接启动事务？
A：事务应由调用实体的应用层或工作流控制，确保事务边界清晰。

业务容器（Business Container）
- 定位：位于系统中间层，封装核心业务逻辑（如图13-10所示）。
- 作用：
  - 解耦表现层与业务层：表现层仅传递参数至容器，避免业务代码渗透到UI层。
  - 支持Domain Model-Service-Control模式：领域模型（Domain Model）封装业务实体，服务层（Service）提供接口，控制层（Control）协调流程。
与SOA融合
- 业务容器可视为轻量级SOA实现，通过服务接口暴露功能，支持未来微服务化扩展。