MVC已过时，MOVE时代来临？（转载）

http://blog.youkuaiyun.com/zhang957411207/article/details/7761283

http://cirw.in/blog/time-to-move-on

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作为一个新技术，在原有的基础上进行升级，以更好的适应软件开发的需求。

原文：http://cirw.in/blog/time-to-move-on

MVC is dead, it's time to MOVE on.

Conrad Irwin — June 2012

MVC is a phenomenal idea. You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of …

What?

I'm certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it.

To fix this I've been using a new pattern: MOVE. Models, Operations, Views, andEvents.

Overview

I'll define the details in a minute, but this diagram shows the basic structure of a MOVE application.

• Models encapsulate everything that your application knows.
• Operations encapsulate everything that your application does.
• Views mediate between your application and the user.
• Events are used to join all these components together safely.

In order to avoid spaghetti code, it's also worth noting that there are recommendations for what objects of each type are allowed to do. I've represented these as arrows on the diagram. For example, views are allowed to listen to events emitted by models, and operations are allowed to change models, but models should not refer to either views or operations.

Models

The archetypal model is a "user" object. It has at the very least an email address, and probably also a name and a phone number.

In a MOVE application models only wrap knowledge. That means that, in addition to getters and setters, they might contain functions that let you check "is this the user's password?", but they don't contain functions that let you save them to a database or upload them to an external API. That would be the job of an operation.

Operations

A common operation for applications is logging a user in. It's actually two sub-operations composed together: first get the email address and password from the user, second load the "user" model from the database and check whether the password matches.

Operations are the doers of the MOVE world. They are responsible for making changes to your models, for showing the right views at the right time, and for responding to events triggered by user interactions. In a well factored application, each sub-operation can be run independently of its parent; which is why in the diagram events flow upwards, and changes are pushed downwards.

What's exciting about using operations in this way is that your entire application can itself be treated as an operation that starts when the program boots. It spawns as many sub-operations as it needs, where each concurrently existing sub-operation is run in parallel, and exits the program when they are all complete.

Views

The login screen is a view which is responsible for showing a few text boxes to the user. When the user clicks the "login" button the view will yield a "loginAttempt" event which contains the username and password that the user typed.

Everything the user can see or interact with should be powered by a view. They not only display the state of your application in an understandable way, but also simplify the stream of incoming user interactions into meaningful events. Importantly views don't change models directly, they simply emit events to operations, and wait for changes by listening to events emitted by the models.

Events

The "loginAttempt" event is emitted by the view when the user clicks login. Additionally, when the login operation completes, the "currentUser" model will emit an event to notify your application that it has changed.

Listening on events is what gives MOVE (and MVC) the inversion of control that you need to allow models to update views without the models being directly aware of which views they are updating. This is a powerful abstraction technique, allowing components to be coupled together without interfering with each other.

Why now?

I don't wish to be misunderstood as implying that MVC is bad; it truly has been an incredibly successful way to structure large applications for the last few decades. Since it was invented however, new programming techniques have become popular. Without closures (or anonymous blocks) event binding can be very tedious; and without deferrables (also known as deferreds or promises) the idea of treating individual operations as objects in their own right doesn't make much sense.

To re-iterate: MVC is awesome, but it's designed with decades old technologies. MOVE is just a update to make better use of the new tools we have.

P.S. I'm not the only one beginning to think this way either, if you like the idea of MOVE you should check out  objectify and  interactions which try to add some of the benefits of MOVE to existing MVC applications. Please  let me know if you have other links that should be here!

P.P.S This blog post has been translated into Japanese no fewer than twice:  d.hatena.ne.jp and blog.neo.jp, and also into  Russian and  Spanish Thanks!