软件架构风格 – welfear

如果说设计模式是从代码角度为系统降低耦合度,那么架构风格便是从数据角度解耦。
架构是更加宏观和全面的视角,它不再是解决单一的技术问题,而是为系统提供更加
完整的解决方案。

架构风格是一种粗粒度的软件模式,为常见软件问题提供解决方案,促进软件的重用。
常见的软件架构风格如下:

1.Pipe & Filter
2.Batch
3.VM
4.Layered Architecture

5.MVC, PAC
6.MicroKernel
7.Event System
8.Blackboard System

9.Broker, C/S, P2P, SOA

参考http://www.infoq.com/news/2009/02/Architectural-Styles-Patterns

每种架构风格适用于某种特定的问题域,比如第九项全部是分布式计算领域的架构风格。

从用户最常见的GUI和CUI环境视角看:
CUI常常是具有单一输入和单一输出,比较擅长处理有机械性、重复性和规律性的问题。
GUI更擅长有交互性的任务,它的输入和输出之间时常会变化并加以排列组合。

CUI和GUI是一种演化的关系:

1.当输入是单一流或者多个单一流时,架构风格往往是Pipe & Filter/Batch/N Layered。
2.当输入是多个流时,架构风格通常是MVC/PAC。
3.当需要合并多个输入流时,则会使用Event System/MicrosKernel。
4.当需要合并多个输出流时,则会使用Blackboard System。

对于1,在Linux中系统管理员和程序员常用Pipe & Filter处理文本流;而在流媒体系统中,
Pipe & Filter用来demux视频流和音频流。这种固定输入流的任务很容易实现批量功能而
变成Batch状态。VM虚拟机可以简单看作是复杂输入而没有相应输出的任务。Layed Arch
是一种存在依赖的Pipe & Filter,它的处理顺序和流程已经事先设定好。

对于2,MVC不仅仅是设计模式,当它能解决多个输入流问题时,它成为为一种架构风格。
MVC以及其衍生的MVVC, MVP, PAC将输入模块,数据模块和协调控制模块分解开来。类似的
模型比较强调Control的作用。

对于3和4,它们常常和MVC共同使用。3, 4代表一种处理更复杂问题的一般思路。数据可能
是输入或输出,也可能是一种解耦的方式。比如实现接口的虚表就是一种解耦数据。直接
传递数据会降低系统性能,上下文情景分析和有效数据分离都会增加计算时间开销。
Event System往往会维护原始的上下文和当前变化数据的信息,这些数据出现在输入流的
最开始处理阶段或着是前后处理模块的衔接过程。Blackboard System强调了Model的作用,
拥有共同的Model特别是Domain Model可以在更宏观的层面上为系统解耦或接入更多的
生产者与消费者。

Tagged:

Comments are closed.