文章目录
- 经典架构风格对比
- 面向对象架构风格/显示调用风格
- 优点
- 缺点
- 举例
- 事件驱动的系统/隐式调用风格
- 优点
- 缺点
- 举例
- 基于规则的系统架构风格
- 优点
- 缺点
- 举例
- 管道过滤器风格
- 优点
- 缺点
- 举例
- 仓库风格
- 优点
- 缺点
- 举例
- 解释器风格
- 优点
- 缺点
- 举例
- 分层架构风格
- 优点
- 缺点
- 举例
经典架构风格对比
面向对象架构风格/显示调用风格
优点
- 一个对象对外隐藏了自己的详细信息。
- 对象将数据和操作封装在一起。
- 继承和封装方法为对象复用提供了技术支持。
缺点
- 如果一个对象要调用另一个对象，则必须知道它的标识和名称。
举例
一般业务系统
事件驱动的系统/隐式调用风格
优点
- 事件发布者不需要知道哪些构件会响应事件。
缺点
- 构件放弃了对计算的控制权，完全由系统来决定。
- 存在数据传输的问题。
举例
消息队列
基于规则的系统架构风格
优点
- 规则数据可以动态更改，灵活性好。
- 定义新的规则，即可扩展。
缺点
- 实时解释规则，性能较差。
举例
规则引擎
管道过滤器风格
优点
- 简单性。
- 支持复用。
- 便于系统分析。
缺点
- 不适合用来设计交互式应用系统。
- 由于没有通用的数据传输标准，因此每个过滤器都需要解析输入数据和合成数据。
- 难以进行错误处理。
举例
流程引擎
仓库风格
优点
- 便于多客户共享大量数据，而不必关心数据时何时产生的，由谁提供的，通过何种途径来提供。
缺点
- 对共享数据结构，不同知识源要达成一致。
- 需要同步机制和加锁机制来保证数据的完整性和一致性，增大了设计的复杂度。
举例
数据仓库
解释器风格
优点
- 可移植性好。
缺点
- 由于使用了特定语言和自定义操作规则，因此增加了系统运行的开销。
- 解释器系统难以设计和测试。
举例
编译器
分层架构风格
优点
- 设计者可以将系统分解为一个增量的步骤序列，从而完成复杂的业务逻辑。
- 每一层最多和相邻的上下两层进行交互，只给相邻层提供相同的接口。
缺点
- 并非所有系统都能够按照层次来进行划分。
- 很难找到一种合适和正确的层次划分方法。
- 传输数据需要经过多个层次。
- 多层结构难以调试。
举例
OSI协议，MVC架构，DDD架构，Cola架构。