MVC已死，是时候转向MOVE了(MVC is dead, it‘s time to MOVE on）

MVC 模式在编程中的应用，是一个很了不起的主意。“数据模型（Model）”可以封装与应用程序的业务逻辑相关的数据及对数据的处理方法；“视图层（View）”能够实现数据有目的的显示；“控制器（Controller）”能够在不同层面间起到组织作用，对应用程序的流程进行控制。

　　不过，可能你在使用这种三层架构模式的过程中会逐渐迷惑。因为有很多代码你不知道把它放哪，就只好把它放到控制层，最后发现在控制层中塞了太多的代码。

　　LinkedIn 的软件工程师 Conrad Irwin 也遇到同样的问题，于是他开始使用另一种模式：MOVE，即 Models（模型）、Operations（操作）、Views（视图）、Events（事件）。近日 Conrad Irwin 在个人博客上分享了关于这种模式的一些观点。

　　概述

　　Irwin 结合上图对 MOVE 模式先作了简单定义：

Models，封装该应用程序中知道的一切；

Operations，封装该应用程序要做的一切；

Views，帮助用户与应用程序完成交互；

Events，用于安全地连接所有这些组件。

　　为了避免意大利面条式的代码，图中标示出了对哪种类型的对象进行操作是允许的。例如，视图允许监听由模型产生的事件；操作允许修改模型，但模型不应涉及视图或操作。

　　Models（模型）

　　这里以一个“User”对象为原型，它至少应用有一个 Email 地址，也可能有用户名和电话号码。

　　在一个 MOVE 模式的 Models 中只包装知识。这意味着除了 Get 和 Set 功能，它们可以包含检查用户密码是否正确这样的方法，但不会包含把密码保存到数据库或传递给外部 API 这样的功能，因为后面这些工作将由 Operations 来完成。

　　Operations（操作）

　　对应用程序来说，一个常见的操作是用户登陆。这实际上是由两个子操作组成：首先从用户那里获得邮件地址和密码，然后从数据库载入“user”模型并检查密码是否匹配。

　　Operations 是 MOVE 模式中的行动者。它负责修改模型，在正确的时间显示正确的视图，以及响应由用户交互引发的事件。在一个分解良好的应用程序中，每个子操作都可以独立运行。

　　采用这种方式的操作有一点很令人振奋，即程序启动后，整个应用本身就可以被当作一个 Operations。它会根据需要生成尽可能多的子操作，其中每个子操作都并行地运行。当所有子操作都完成时，程序也便退出。

　　Views（视图）

　　登陆页面即是一个视图，它负责显示一些文本框给用户。当用户点击“登陆”按钮时，视图将产生一个“loginAttempt”事件，其中包含用户输入的用户名和密码。

　　用户能够看到的内容，以及能感受到的互动都由视图提供支持。它们会以一种用户能理解的形式呈现应用反馈，同时还能将简单的用户交互转换成有意义的事件。更重要的是视图不会直接改变模型，它们只是向 Operations 发起事件，然后通过监听等待由模型发起的事件。

　　Events（事件）

　　当用户登陆时，视图会发起“loginAttempt”事件。在登陆操作完成后，“currentUser”模型会发起一个事件通知应用登陆状态已改变。

　　事件监听让 MOVE（及 MVC）实现控制反转，允许模型更新视图。这是一种强大的抽象技巧，允许组件互不干扰地耦合在一起。

　　为什么是现在？

我不想被误解为暗示MVC不好。在过去的几十年中，它确实是构建大型应用程序的一种非常成功的方法。然而，自从它被发明以来，新的编程技术已经变得流行。如果没有闭包（或匿名块），事件绑定将非常繁琐。如果没有可延期付款（也称为延期付款或承诺），则将单独的操作本身视为对象的想法没有多大意义。

PS我也不是唯一一个以这种方式思考的人，如果您喜欢MOVE的想法，则应检查一下对象化和交互作用，以尝试将MOVE的某些优点添加到现有MVC应用程序中。如果您还有其他链接，请告诉我！

PS该博客文章已被翻译成日语，其中包括d.hatena.ne.jp和blog.neo.jp不少于两次，还被翻译成俄语，韩语和西班牙语。谢谢！