为了构建Android-Tractor，我寄希望找到一个前端的架构 模式。在上一篇文章中，我们对三个比较典型的模式:MVC、MVP、Presentation Model做了简单的分析。分析的结果是：它们都有些不尽人意。
所以，在这篇文章中，我提出一个新的模式：反射弧模式。大家听到 反射弧 可能会感觉很熟悉，那就对了。大家念初中的时候，生物课上都讲过这个。不信？你 搜一下百度百科，估计就能打开尘封的记忆了。在百度百科中，反射弧的定义是：执行反射的全部神经结构。它一般包括五部分：感受器、传入神经纤维、中枢、传 出神经纤维和效应器。现在的工具越来越智能化，比如机器人、比如说搜索里面的语义识别、自我学习等等。从另一个角度来说，它们越智能，越接近人。反射活动 是用在人身上的。如果人也是程序或者说工具、那么反射弧就是女娲（如果有的话）造人（程序）的时候，所采用的架构模式。而且这个模式已经用了不知道多少 年，至少，到目前，还没什么大问题的，哈哈。
我们现在结合程序这个特定的领域，来对反射弧做少许改造。传入、传出神经纤维是用来通讯的，所以去掉（在程序中，通讯是一个最基本的主题，在关键问题章节，我们对通讯的解决方案做 了简单归纳，大家有兴趣可以看看）。中枢主要职责是业务逻辑，我们用更计算机的语言：业务模型来替换它。最后加上视图和外部数据，外部数据就用模型这个概 念来表示，只不过这个模型主要以数据为主。
下面，我们正式定义反射弧模式。
反射弧模式
概念
反射弧模式是一个客户端框架模式，它把程序分成5个部分：视图、感受器、效应器、业务模型、模型。
结构图
组件
视图是程序的显示部分，由窗口和控件组成。
感受器负责监控、识别用户操作，并把这些操作传递给业务模型。
效应器负责监控来自模型或者业务模型的变化，并把这些变化按照一定的逻辑应用到 视图上。
业务模型负责程序的业务逻辑，包括业务行为和一些临时性数据。它接收感受器发送来的操作，根据操作来执行一定的业务逻辑，并且把最终结果传递给模型。
模型代表了程序的永久性数据。对于具体程序而言，是它所在世界的抽象。
交互
先看一张图用来表示反射弧系统中某一运行时可能的情况：
结合图，我们来说说反射弧模式中的交互情况。
在反射弧模式中，每一个视图都有其对应的感受器和效应器，是一一对应的关系，感受器感知该视图上低级操作，识别用户行为。
视图和业务模型是多对1的关系，多个视图可能使用一个业务模型。视图可能是一个Form级别的控件，但是业务模型可能是一个子系统，包括众多的业务对象， 它们相互协作。感知器把行为转发给业务模型的facade对象上。业务模型看不见视图，也看不见视图对应的感受器和效应器，但是可以看见模型，业务模型执 行用户行为，在一定条件下，改变模型。
效应器通过观察者模式来得到业务模型或者模型的改变，针对这些改变，有可能需要解析模型数据，有可能需要改变视图的其他相关属性，这一切都用效应器来决 定。
