Mikel
[转载]MVC已死，该是用MOVE的时候了 – Ron Ngai – 博客园.
MVC已死，该是用MOVE的时候了
- 学习新技术，希望与博友共勉之
- 提升总结和翻译
- 记录自己学习的过程
MVC模式是一种不一般的设想。MVC模式包含有封装业务逻辑和数据处理的数据模型层（Models），显示用户界面的视图层（Views）和控制和连接模型层和视图层的控制层（Controllers）。
什么？
Conrad Irwin很肯定他不是第一个发现下面这一点的。当你不清楚在那里写代码的时候，MVC会带来让你将过多的代码写在控制层（Controllers）的问题。
为了解决这个问题，我采用一种新的模式：MOVE。模型层（Models），操作层（Operations），视图层（Views）和事件层（Events）。
概念
图片显示了MOVE模式的基本结构，下面是对每个层的解释：
- 模型层（Models）封装应用程序所知道的一切。
- 操作层（Operations）封装应用程序所作的一切。
- 视图层（Views）完成用户与应用程序的交互。
- 事件层（Events）被用于安全地连接组件。
模型层（Models）
创建一个原型模型即一个“user”对象。它至少有一个用户名（email），或许还有一个名字（name）和电话号码（number）。
在一个MOVE模型应用程序中，模型层（Models）只用于包装知识。意思是，它包含让 你验证“这是否是用户密码？”的函数来让获取（getters）和设置（setters）属性值。但是它不包含让你保存它们到数据库或者上传到一个外部 API的函数。这是操作层（Operations）的事情。
操作层（Operations）
一个基本的操作例子就是让用户登录。这分两个字操作来完整。第一，获取用户的用户名（email）和密码（password）。第二，加载调用从数据库查询出数据而设置好的的“user”模型，验证密码是否正确。
操作层（Operations）是MOVE模型世界的执行者。它的职责是设置的模型层 （Models），在正确的时间调用显示正确的视图层（Views）以及相应用户触发引起的事件层（Events）。在一个好的应用程序中，每一个子操作 都可以在父操作下独立运行。这也是为什么图表中事件层中流往上走和改变往下走。
用操作层（Operations）这种方式让人惊讶之处在于，当程序重启开始的时候，你的整个应用程序可以视为是一个操作（Operation）。根据需要被分为多个子操作。同时，每一个字操作可以并行存在运行。另外，当所有字操作运行完成时，程序退出。
视图层（Views）
登录界面是一个显示若干文本框给用户的一个视图（View）。当用户点击“Login”按钮，视图（View）会产生一个包含用户输入用户名和密码的“loginAttempt”的事件（event）。
用 户能看到和能交互的所有事情应该被建设为一个视图（view）。它们不但不显示应用程序在不明方式下的状态，而且将用户产生的交互简化为有意义的事件 （Events）。重要的是，视图（views）不会直接改变模型（models），它们简单地触发事件到操作，然后等待由模型触发事件所引起的改变。
事件层（Events）
事件“loginAttempt”是由于用户点击登录的视图触发的。另外，当登录操作完 成，“currentUser”模型会触发事件，将模型引起的改变通知应用程序。监听事件是让MOVE模式（和MVC模式）的一种逆控制。这种控制是在模 型没有直接意识到视图在更新的时候，你允许模型更新视图。这是一种高度抽象的技术。这种技术允许组件相互存在而又相互不影响。
为什么该是时候了？
Conrad Irwin不希望被误解成这表示MVC已死。在 过去的十几年中，MVC在大型结构的应用程序当中确实获取了令人难以置信的成功。它出现十几年了，但是，新的编程技术已经越来越流行。没有它的自闭性（或 者匿名块），事件绑定变得非常乏味。没有它的延期和承诺，这种用各自权限处理当对象看的各自层次操作的思想不会有什么意义。
再次重申：MVC很棒，但是这是几十年前设计的老技术了。MOVE是一种更好用的新工具。
备注：Conrad Irwin不是唯一开始思考这种模式的人。如果你喜欢MOVE，你可以查看objectify和interactions文章。里面除了阐述MVC程序之外还试图解释了MOVE的好处。如果你有其他的连接应该出现在这里，你可以告诉我。
再次备注：这篇文章被翻译为日语不止两次：d.hatena.ne.jp 还有 blog.neo.jp. 谢谢！
//坐等吐槽….
文章原文来自“MVC is dead, it’s time to MOVE on.”。可能存在不准确翻译，推荐阅读“MVC模式已死？何不试试MOVE”。
