从MVC框架看MVC架构的设计.docxVIP

从MVC框架看MVC架构的设计 2021-07-04 虽然MVC早已不是什么新颖话题了，但是从近些年一些优秀MVC框架的设计上，我们还是会发觉MVC在架构设计上的一些新亮点。本文将对传统MVC架构中的一些弊病进行解读，了解一些优秀MVC框架是如何化解这些问题的，揭示其中所折射出的设计思想与设计理念。 MVC回顾 作为一种经典到不能再经典的架构模式，MVC的成功有其必定的道理，这个道理不同的人会有不同的解读，笔者最认同的一种观点是：通过把职责、性质相近的成分归结在一起，不相近的进行隔离，MVC将系统分解为模型、视图、把握器三部分，每一部分都相对独立，职责单一，在实现过程中可以专注于本身的核心规律。MVC是对系统简单性的一种合理的梳理与切分，它的思想实质就是“关注点分别”。至于MVC三元素的职责划分与相互关系，这里不再赘述，下图给出了格外细致的说明。 图1：MVC组件的功能和关系[i] View与Controller的解耦：mediator+二次大事委派 笔者早年开发基于swing的GUI应用时,在架构MVC的实践过程中深刻体会到了view与controller之间的紧密耦合问题。在很多大事驱动的GUI框架里，如swing，用户对view的任何操作都会触发一个大事，然后在listener的响应方法里进行处理。假如让view本人注册成为大事的listener,则必需要在view中加入对controller的引用，这不是MVC期望看到的，由于这样view和controller就构成了紧密的耦合关系。若将controller注册为listener，则大事响应将由controller担当，这又会导致controller处理其不该涉及的呈现规律,形成view和controller难以解耦的缘由在于：多数的用户恳求都包含肯定成分的呈现规律和肯定成分的业务规律，两种规律揉合在一个恳求里，在处理的时候，view与controller很难合理地分工。处理这一问题的关键是要在view与controller之间建立一种可以将呈现规律与业务规律进行有效分割的机制，在这方面，PureMVC[ii]的设计格外值得参考，它通过引入mediator+二次大事委派机制很好的处理了view与controller之间的紧耦合问题。 Mediator是一种设计模式，这种模式在组件化的图形界面框架中好像有着普遍的应用场景，即便是在“四人帮”的《设计模式》一书中，也使用了一个图形界面程序的示例来讲解mediator。mediator的设计意图在于通过一个媒介对象，完成一组对象的交互，避开对象间相互引用，产生简单的依靠关系。mediator应用于图形界面程序时，往往作为一组关系紧密的图形组件的交互媒介，完成组件间的协调工作(比如点选某一按钮，其他组件将不行用)。在PureMVC中，mediator被广泛应用，其定位也发生了微妙的变化，它不再只是图形组件间的媒介，同时也成为了图形组件与command之间的媒介，这使得它不再是可选的，而是成为了架构中的必需设备。对应到传统MVC架构中，mediator就是view与controller之间的媒介（当然，也照旧是view之间的媒介），全部从view发出的用户恳求都经过了mediator再传递给controller，它的消灭在肯定程度上缓解了view与controller的紧密耦合问题。 当view、mediator和controller三者被定义出来，并进行了清楚的职责划分后，剩下的问题就是如何将它们串联起来，以完成一个用户恳求了，在这方面，大事机制起到了至关重要的作用。大事机制可以让当前对象专注于处理其职责范围内的事务，而不必关怀超出部分由谁来处理以及怎样处理，当前对象只需要广播一个大事，就会有对此大事感爱好的其他对象出来接手下一步的工作，当前对象与接手对象之间不存在直接依靠，甚至感知不到彼此的存在，这是大事机制被普遍认为是一种松耦合机制的重要缘由。讲到这里插一句题外话，在领域驱动设计（Domain-Driven Design）里，有名的Domain Event模式也是有赖于大事机制的这一特性被制造出来的，其意图正是为了保证领域模型的纯洁，避开领域模型对repository和service的直接依靠。回到PureMVC, 我们来看在处理用户恳求的过程中，大事机制是如何串联view、mediator和controller的。在PureMVC里，当一个用户恳求下达时，图形组件先在本身的大事响应方法中实现与本身相关的呈现规律，然后收集数据，将数据置入一个新的event中，将其广播出去，这是第一次大事委派。这个event会被一个mediator监听到，假如处理该恳求需要其他图形组件的帮忙，mediator会协调它们处理应由它