架构风格对比和分析
| 架构风格名称 | 灵活性 | 可扩展性 | 性能 | |||||||||
| 面向对象 | 将用户级别、折扣规则等封装为对象，在系统启动时加载 | 加入新的用户级别和折扣规则时，需要重新定义新的对象，并需要重启系统 | 用户级别和折扣规则已经在系统内编码，可直接运行，性能较好 | |||||||||
| 基于规则 | 将用户级别、折扣规则等描述为可动态改变的规则数据 | 加入新的用户级别和折扣规则时需要定义新的规则，解释规则即可进行扩展 | 需要对用户级别与折扣规则进行实时解释、性能较差 | |||||||||
| 架构风格名称 | 数据处理方式 | 系统可扩展性 | 处理性能 | |||||||||
| 管道-过滤器 | 数据驱动机制，处理流程事先，交互性差 | 数据与处理紧密关联，调整处理流程需要系统重新启动 | 劣势：需要数据格式转换，性能降低 优势：支持过滤器并发调用，性能提高 | |||||||||
| 仓库 | 数据仓储在中心仓库，处理流程独立，支持交互式处理 | 数据与处理解耦合，可动态添加和删除处理组件 | 劣势：数据与处理分离，需要加载数据，性能降低 优势：数据处理组件之间一般无依赖关系，可并发调用，提高性能 | |||||||||
| 架构风格 | 主要特点 | 主要优点 | 主要缺点 | 适合领域 | ||||||||
| 管道-过滤器 | 过滤器相对独立 | 功能模块复用；可维护性和可扩展性较强；具有并发性；模块独立性高 | 不适于交互性强的应用，对于存在关系的数据流必须进行协调 | 系统可划分清晰的模块；模块相对独立；有清晰的模块接口 | ||||||||
| 面向对象 | 力争实现问题空间和软件系统空间结构的一致性 | 高度模块性；实现封装；代码共享灵活；易维护；可扩充性好 | 增加了对象之间的依赖关系 | 多种领域 | ||||||||
| 事件驱动 | 系统由若干子系统构成且称为一个整体；系统有统一的目标；子系统有主从之分；每个子系统有自己的事件收集和处理机制 | 适合描写系统组；容易实现并发处理和多任务；可扩展性好；具有类层次结构；简化代码 | 因为树型结构所以消弱了系统计算的控制能力；各个对象的逻辑关系复杂 | 一个系统对外部对表现可以从它对时间的处理表征出来 | ||||||||
3320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
