8. 模型-视图-控制器模式(MVC模式)
该模式亦被称为MVC模式，它将交互式应用分成3个部分，
模型 – 包含核心功能和数据
视图 – 给用户展示信息（可能不止一个视图）
控制器 – 处理用户的输入 这样做的目的是将 信息的内部表示 和 信息呈现给用户并且从用户获取的方式 分离开。这样能解耦组件并且有效重用代码。
用法
主要编程语言的万维网应用的体系结构。
web框架，例如Django和Rails。
9. 黑板模式
该模式可用于没有已知确定性解决方案策略的问题。黑板模式由3个主要组件组成。
黑板 – 一块结构化的全局内存，包含解决方案空间的对象。
知识源 – 具有各自代表性的专业模块。
控制组件 – 选择，配置和执行模块。 所有组件都可以访问黑板。组件可能会生产添加进黑板的新数据对象。组件在黑板上寻找特定类型的数据，并且可能利用已有的知识源，通过模式匹配的方式来寻找数据。
用法
语音识别
车辆识别和追踪
蛋白质结构识别
海纳信号解析
10. 解释器模式
该模式用于设计 用来解释专用语言写成的程序 的组件。它主要指明如何评估程序的行，即用特定语言编写的语句或表达式。基本想法是为语言的每个符号设置一个类。
用法
数据库查询语言，例如SQL。
计算机语言用来描述通讯协议。
架构模式的优劣比较
下面的图表总结了各种架构模式的优劣。
|
名字 |
优势 |
劣势 |
|
分层模式 |
低层级的组件能被不同的高层级组件调用。可以清晰地定义层级，所以层级化更容易标准化。当在层级内改动时不会影响到其他层级 |
不是普遍适用的。在某种情况下，某些层级可能会被跳过 |
|
客户端-服务端模式 |
能很好地对客户端请求的服务进行建模 |
请求被分到服务端的不同的线程中处理。因为不同的客户端有不同的展示形式，进程间通讯会导致额外开销。 |
|
主从模式 |
准确性 – 服务被代理到具有不同实现的从属组件中执行 |
从属组件彼此隔离：之间没有共享状态。主从通讯的延迟在某些场景下是个问题，例如实时系统。这种模式只可以被用来解决能被分解的问题。 |
|
管道过滤模式 |
并行处理。当输出和输出都是流数据，过滤器一旦收到数据便开始计算。易于增加过滤器，系统扩展性好。过滤器可以复用。可以通过已有过滤器的重新组合来构建不同的管道 |
效率会受限于最慢的过滤处理器。把数据从一个过滤器转移到另一个中时，存在数据转换的开销。 |
|
代理模式 |
允许对象动态变化，增加、减少和迁移，并且对象分布对开发者是透明的。 |
需要服务描述标准化。 |
|
点对点模式 |
支持分布式计算。对于任意失败节点的高健壮性。取决于资源和计算效率的高拓展性。 |
由于各个节点是自愿合作的，服务质量无法保证。安全性很难保证。性能取决于节点数量。 |
|
事件总线模式 |
易于新增发布者、订阅者和连接。该模式对于高分布式应用很奏效。 |
该模式的可拓展性可能是个问题，因为所有消息都通过同一个事件总线传输。 |
|
模型-视图-控制器模式 |
相同的模型可以轻松拥有多个视图，可以在运行时建立连接和断开连接。 |
复杂度增加。可能导致用户操作的许多不必要的更新。 |
|
黑板模式 |
易于新增应用。易于扩展数据空间的结构。 |
很难修改数据空间的结构，因为会影响所有应用。可能需要同步和访问控制。 |
|
解释器模式 |
有可能实现高度动态行为。有利于终端用户的可编程性。提高灵活性，因为易于替换解释代码。 |
因为解释语言的执行速度一般比编译语言慢，所以性能可能是个问题。 |