MVC工作机制

Posted 2021-05-01 Java引导者

View、Mediator和Controller

当view、mediator和controller三者被定义出来，并进行了清晰的职责划分后，剩下的问题就是如何将它们串联起来，以完成一个用户请求了，在这方面，事件机制起到了至关重要的作用。事件机制可以让当前对象专注于处理其职责范围内的事务，而不必关心超出部分由谁来处理以及怎样处理，当前对象只需要广播一个事件，就会有对此事件感兴趣的其他对象出来接手下一步的工作，当前对象与接手对象之间不存在直接依赖，甚至感知不到彼此的存在，这是事件机制被普遍认为是一种松耦合机制的重要原因。回到MVC，我们来看在处理用户请求的过程中，事件机制是如何串联view、mediator和controller的。在MVC里，当一个用户请求下达时，图形组件先在自身的事件响应方法中实现与自身相关的展现逻辑，然后收集数据，将数据置入一个新的event中，将其广播出去，这是第一次事件委派。这个event会被一个mediator监听到，如果处理该请求需要其他图形组件的协助，mediator会协调它们处理应由它们承担的展现逻辑，然后mediator再次发送一个event（这次的event在MVC里称之为notification），这个event会促使某个command执行，完成业务逻辑的计算，这是第二次事件委派。在两次事件委派中，第一次事件委派让当事图形组件完成“处理其职责范围内的展现逻辑”后，得以轻松“脱身”，免于被“协调其他图件处理剩余展现逻辑”和“选择并委派业务对象处理业务逻辑”所拖累。而“协调其他图形组件处理剩余展现逻辑”显然是mediator的职责，于是第一次广播的事件被委派给了mediator。mediator在完成图形组件的协调工作后，并不会插手“选择并委派业务对象处理业务逻辑”的工作，这不是它的职责，因此，第二次事件委派发生了，一个新的event由mediator广播出去，后被某个command响应到，由command完成了最后的工作——“选择并委派业务对象处理业务逻辑”。

mediator+二次事件委派机制

总结起来，MVC是通过在view与controller之间引入mediator，让view与controller变成间接依赖，用户请求从view到mediator，再从mediator到controller均以事件方式委派，mediator+二次事件委派的组合可以说是一种“强力”的解耦机制，它实现了view与controller之间的完全解耦。

从Controller到Command，自然粒度的回归

目前，很多平台的主流MVC框架在设计上都引入了command模式，command模式的引入改变了传统MVC框架的结构，受冲击最大的就是controller。在过去传统的MVC架构里，一个controller可能有多个方法，每个方法往往对应一个user action，因此，一个controller往往对应多个user action，而在基于command的MVC架构里，一个command往往只对应一个user action。传统MVC架构里将一个user action委派到某个controller的某个方法的过程，在基于command的MVC架构里变成了将useraction与command一一绑定的过程。如果说传统controller的管理方式是在user action与model之间建立“集中式”的映射，那么基于command的管理方式就是在user action与model之间建立“点对点式”的直连映射。　　

从基于Controller到基于Command的架构演进

主流MVC框架向command转型是有原因的，除了command自身的优势之外，一个非常重要的原因就是：由于缺少合理的组织依据。controller不同于view与model，view与model都有各自天然的粒度组织依据，view的组织粒度直接承袭用户界面设计，model的组织粒度则是依据某种分析设计思想（如OOA/D）进行领域建模的结果，controller需要同时协调view与model，但是view与model的组织结构和粒度都是不对等的，这就使得controller面临一个“在多大视图范围内沟通与协调多少领域对象”的问题，由于找不出合理的组织依据，设计者在设计controller时往往感到无所适从。相比之下，command则完全没有controller的困惑，因为command有一个天然的组织依据，这就是user action。针对一个user action设计一个command，然后将两者映射在一起，是一件非常自然而简单的事情。不过，需要说明的是这并不意味着所有command的粒度是一样的，因为不同的user action所代表的业务量是不同的，因此也决定了command是有大有小的。遵循良好的设计原则，对某些较“大”的command进行分解，从中抽离出一些可复用的部分封装成一些较“小”的command是值得推荐的。很多MVC框架就定义了一些相关的接口和抽象类用于支持基于组合模式的命令拼装。

不管是基于controller还是基于command，MVC架构中界定的“协调view与model交互”的控制器职责是不会变的，都需要相应的组件和机制去承载与实现。在基于command的架构里，command承担了过去controller的部分职责，从某种意义上说command是一种细粒度的controller，但是command的特性是偏“被动”的。一方面，它对于view和model的控制力比controller弱化了很多， 比如，一般情况下command是不会直接操纵view的。另一方面，它不知道自己与什么样的user action映射在了一起，也不知道自己会在何种情况下被触发执行。支撑command的运行需要额外的注册、绑定和触发机制，是这些机制加上command一起实现了controller的职责。由于现在多数基于command的MVC框架都实现并封装了这些重要的机制，所以从某种意义上说，是这些框架自身扮演了controller角色。