MVC已过时，MOVE时代来临？

转自:http://sd.csdn.net/a/20120709/2807210.html

MVC已过时，MOVE时代来临？

MVC是一个很常用的程序开发设计模式，M-Model（模型）：封装应用程序的状态；V-View（视图）：表示用户界面；C-Controller（控制器）：对用户的输入作出反应，创建并设置模型。

关于这个话题由来已久，MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。在实际使用中，开发人员在不知道把代码放在哪里的时候，都喜欢把代码放在Controller里面。

为了解决上述问题，LinkedIn的软件工程师Conrad Irwin开始使用另一种模式：MOVE采用了一个新的模型：MOVE：Model，Operation，View and Event。日前Conrad Irwin在个人博客上分享了关于这种模式的一些观点。

上面这张图显示了MOVE这个模式的基本架构。下面详细介绍一下该模式：

• Model：封装所有应用程序对象。
• Operation：封装所有应用程序执行的动作。
• View：应用程序和用户之间的中介。
• Event：链接所有组件事件。

为了避免面条式代码，应该允许每种对象类型。在上图中，已经用箭头标明出来，例如，View允许通过Mdoel去监听Event、可以允许改变模型，但Model不应该只参照View或Operation。

Model

以一个“用户”对象为例，这个Model至少有一个email、姓名和电话号码这几个属性。

在MOVE应用程序模型中Model只封装了简单的方法。这也就意味着除了getters和setters，还会包含一些验证函数，比如：“密码正确吗？”。但不包含把数据保存到数据库或者加载数据到外部API中的方法，这些都应该是Operation来完成的事情。

Operation

应用中，比较常见的Operation应用是一个用户登录程序。它实际上是由两个子操作完成的：首先，从user中获取邮箱地址和密码，其次从数据库中读取user对象信息，并且检查两者数据是否匹配。

在MOVE模型中，Operation永远都是一个执行者。负责对Model进行修改、适时显示正确的视图给用户、对用户触发的事件做出响应。在一个分解良好的应用程序中，相对Operation每个sub-operation都可以在其中单独运行。这就是为什么Event箭头向上而Changes向下。

这样做的好处在于：在程序运行时，开发者可以把整个应用当作一个Operation。如果需要，它还可以尽可能地分解为更多的sub-operation，而每一个sub-operation都可以并行运行，然后在它们都结束时程序结束运行。

View

登录界面就是一个视图，显示几个文本框。当用户点击“登录”按钮时，视图将产生一个“loginAttempt”事件，并且把用户输入的用户名和密码传送过去。

视图就是用户看到的整个界面并且用户还可以通过界面与程序进行交互。它们不仅会以一个易于理解的方式来显示应用程序，而且还可以把用户传入的信息简化成有意义的事件来与用户进行交流。

重要的是，视图并不会直接改变模型，它们只会发出事件给Operation，并且等待Model发出事件响应。

Event

用户点击登录按钮时，视图会产生一个“loginAttempt”事件。此外，当登录这个操作完成后，“currentUser”模型会发出一个事件去通知你的应用程序。

事件监听和MVC/MOVE里的控制刚好相反，开发者需要允许Model去更新View，即使在Model不清楚哪个View正在更新。

总结

本文并不是强调MVC有多糟糕，在过去的几十年里，它以难以置信的方式成功构建了许多大型应用程序。但它毕竟是几十年前为老技术而设计的，而MOVE作为一个新技术，在原有的基础上进行升级，以更好的适应软件开发的需求。