为什么要用MVC

Posted 2021-05-01 Java引导者

尽管MVC早已不是什么新鲜话题了，但是从近些年一些优秀MVC框架的设计上，我们还是会发现MVC在架构设计上的一些新亮点。本文将对传统MVC架构中的一些弊病进行解读，了解一些优秀MVC框架是如何化解这些问题的，揭示其中所折射出的设计思想与设计理念。

MVC回顾

作为一种经典到不能再经典的架构模式，MVC的成功有其必然的道理，这个道理不同的人会有不同的解读，我最认同的一种观点是：通过把职责、性质相近的成分归结在一起，不相近的进行隔离，MVC将系统分解为模型、视图、控制器三部分，每一部分都相对独立，职责单一，在实现过程中可以专注于自身的核心逻辑。MVC是对系统复杂性的一种合理的梳理与切分，它的思想实质就是“关注点分离”。至于MVC三元素的职责划分与相互关系，下图给出了非常细致的说明。

MVC组件的功能和关系

View与Controller的解耦：mediator+二次事件委派

我在架构MVC的实践过程中深刻体会到了view与controller之间的紧密耦合问题。在很多事件驱动的GUI框架里，如swing，用户对view的任何操作都会触发一个事件，然后在listener的响应方法里进行处理。如果让view自己注册成为事件的listener，则必须要在view中加入对controller的引用，这不是MVC希望看到的，因为这样view和controller就形成了紧密的耦合关系。若将controller注册为listener，则事件响应将由controller承担，这又会导致controller处理其不该涉及的展现逻辑，造成view和controller难以解耦的原因在于：多数的用户请求都包含一定成分的展现逻辑和一定成分的业务逻辑，两种逻辑揉合在一个请求里，在处理的时候，view与controller很难合理地分工。解决这一问题的关键是要在view与controller之间建立一种可以将展现逻辑与业务逻辑进行有效分割的机制，在这方面，MVC引入mediator+二次事件委派机制很好的解决了view与controller之间的紧耦合问题。

Mediator的引入

Mediator是一种设计模式，这种模式在组件化的图形界面框架中似乎有着普遍的应用场景。mediator的设计用意在于通过一个媒介对象，完成一组对象的交互，避免对象间相互引用，产生复杂的依赖关系。mediator应用于图形界面程序时，往往作为一组关系紧密的图形组件的交互媒介，完成组件间的协调工作(比如点选某一按钮，其他组件将不可用)。mediator被广泛应用，其定位也发生了微妙的变化，它不再只是图形组件间的媒介，同时也成为了图形组件与command之间的媒介，这使得它不再是可选的，而是成为了架构中的必需设施。对应到传统MVC架构中，mediator就是view与controller之间的媒介（当然，也依然是view之间的媒介），所有从view发出的用户请求都经过了mediator再传递给controller，它的出现在一定程度上缓解了view与controller的紧密耦合问题。