软件架构的设计风格

逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。（用户关注）

开发视图：也称为模块(实现)视图，主要侧重于软件模块的组织和管理。（程序员）

进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。（并发，集成人员）

物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。（软件到硬件，系统工程人员）

场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。（用例图）

批处理序列，强调数据作为一个整体（数据必须是完整的，以整体的方式传递）

管道和过滤器，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流. (构件–>过滤器；连接件–>管道) （数据流的形式）

主程序/子程序，计算构件作为子程序协作工作，由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用。

面向对象风格，面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。

层次结构风格，分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度。允许每层用不同的方法实现，为软件重用提供了强大的支持。（二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用）

进程通讯，进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作。

事件系统子风格（隐式调用 ），事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐式调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。

解释器，具有运行时系统行为（自）定义与改变能力，如专家系统。

基于规则的系统，基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。（一般用在人工智能领域和DSS中）

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。

数据库系统，构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态，另一个是多个独立处理元素，处理元素对数据元素进行操作。中央数据库管理系统通过自身机制如数据排它锁，共享锁等，实现数据高速访问，数据一致性，数据完整性。同时各独立数据处理单元之间互相不受约束。(如编译器，传统编译器采用批处理架构，现代编译器采用数据共享架构风格。分析树是共享数据。)

超文本系统，主要应用于静态网页。

黑板风格，由一个作为全局共享数据的黑板，一个控制单元和多个知识源组成，主要应用与专家问题解决系统。通过专家知识和反馈逐步得到正确结果。（如语音识别）

过程控制，工业中的过程控制是指以温度、压力、流量、液位和成分等工艺参数作为被控变量的自动控制。过程控制也称实时控制，是计算机及时的采集检测数据，按最佳值迅速地对控制对象进行自动控制和自动调节，如数控机床和生产流水线的控制等。（比如空调制冷，温度大于设定温度制冷，小于等于时停止，一旦大于继续运作）

C2，通过连接件绑定在一起按照一组规则运作的并行构件。

二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；（使用范围）

软、硬件的组合及集成能力有限；（扩展性）

服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；（性能）

数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。（安全）

表现层（Web层），负责接收客户端请求，向客户端响应结果，通常客户端使用http协议请求Web，Web层需要接收http请求，完成http响应。表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。表现层的设计一般都使用 MVC 模型。MVC 是表现层的设计模型，和其他层没有关系。

业务层 （Service层），它负责业务逻辑处理，和我们开发项目的需求息息相关。web层依赖业务层，但是业务层不依赖Web层。业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。(事务应该放到业务层来控制）

持久层 （Dao层），负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进行持久化的载体，数据访问层是业务层和持久层交互的接口；业务层需要通过数据访问层将数据持久化到数据库中。持久层就是和数据库交互，对数据库表进行增删改査的。

允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。（逻辑独立清晰，可维护性/可扩展性）

允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。（可升级性/开放性）

三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。（开发维护成本/速度/技术门槛）

允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。（安全）

用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。（客户端）

基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。（服务端）

B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。（开放性）

B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

B/S架构的系统扩展能力差，安全性难以控制。

采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。（性能）

B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

Model是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model接受Controller的请求并完成相应的业务处理，在状态改变的时候向View发出相应的通知。

View实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。

View捕获到用户交互操作后会直接转发给Controller，后者完成相应的UI逻辑。如果需要涉及业务功能的调用，Controller会直接调用Model。在完成UI处理后，Controller会根据需要控制原View或者创建新的View对用户交互操作予以响应。

分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；

分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；

分布式数据和应用架构数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机。

架构风格往往是从全局的角度来考虑问题，他是一种独立于实际问题的通用组织结构。例如，常用的B/S架构，在很多不同的系统中，都有应用。

而设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。例如，在很多的软件系统中，创建对象时，希望有统一的机制对这些对象的创建进行管理，所以出现了工厂模式，创建者模式等设计模式。比如Java内存垃圾的回收机制也做成了一种设计模式。

多态性（可替代性）；

模块封装性（高层次信息的隐藏）；

后期的绑定和装载（部署独立性）；

安全性（类型和模块安全性）。