编程与软件工程cirw.in
MVC 已死，是时候转向 MOVE 了
MVC is dead, it's time to MOVE on
2012 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者认为 MVC 在 Web 开发中已被滥用，控制器成了堆积逻辑的“垃圾抽屉”，提出用 MOVE（Models、Operations、Views、Events）替代：把业务逻辑放进 Operations，用事件解耦各部分。文章两次登上 HN 首页，引发关于架构模式是否只是换汤不换药的长久讨论。
为什么经久不衰：它触及了软件架构中“模式名字会过时，但关注点分离不会”的核心争论，无论用 MVC 还是别的缩写，如何安放业务逻辑的问题至今仍在。
HN 评论精选
MOVE 本质上就是 MVC 换了个名字，分层架构早已解决了控制器臃肿问题
这看起来就是 MVC，只是把控制器改叫“操作”。MVC 抽象在 Web 应用中确实有问题，因为请求-响应循环不像它最初设计的硬件-监视器-软件循环那样能提供直接反馈。但如果问题是控制器里塞了太多逻辑，你应该给它找个更好的去处。Java/Spring 里典型的 Controller -> Manager/Service -> DAO 分层就很顺手：控制器解析输入并委托动作，Manager 封装业务逻辑，DAO 负责数据存取。这个方案除了给子系统间通信贴标签外没提供更多东西，而且那些“操作”定义不清，像是另一种埋藏逻辑的模糊方式。
scrame查看英文原文
This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around. However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it. In Java/Spring-MVC, there is a typical class hierarchy of Controller -> Manager/Service -> DAO. The extra level of indirection is a very handy place to put business logic, then each class in the tier has a dedicated function: Controller -- Parses input, delegates the action and returns the response (rendered by the view). Manager -- Handles sanitized data, encapsulates business logic and makes calls into the Model / Data layer. DAO -- Interfaces with the data store, makes sure only good data goes in, and appropriate responses are returned. This approach doesn't seem to offer anything more than that, except for putting a label on the messaging between subsystems, but those operations are not well defined (at least in this piece), and seem like another nebulous way to bury logic. It seems like this problem has arisen from a rather narrow reading of what an MVC system should be, as in, not having utility libraries because they aren't strictly an M a V or a C. *edit: formatting.
检验 MVC 是否用对了的标准：换掉视图层后代码还能复用多少
MVC 比其他设计模式被滥用得更厉害。开发者应记住它的 GUI 血统。我的“是不是 MVC”试金石是：如果我大幅更换视图，多少代码能存活？比如换成新的桌面、Web 或文本控制台界面，能否复用大部分应用？如果视图换不掉，就失去了 MVC 的重要优势。一个保证方法是从一开始就做两个视图——真正要发布的那个，和一个用于测试的无头视图。
jaaron查看英文原文
MVC, more than other design patterns, is horribly abused. Developers should keep in mind its GUI roots. Here's my "is it MVC?" litmus test: How much of my code survives if I drastically change the view? For example, if I want to switch to a new desktop, web or text console interface, can I reuse much of the application? Of course, architecture changes this significantly (particularly web architecture), but still, if I cannot swap out the view, then I'm losing out on one of the significant advantages of an MVC architecture. One way to make sure this works is to start with 2 views from the beginning - the view you're actually going to ship, and a headless view for tests.
服务层是更好的解法，而全面事件化会带来同步和调试难题
我见过最好的 MVC 实践不是把所有逻辑塞进控制器，而是建一个由控制器调用的“服务”或“管理器”层，比如 userService.login(name, password)。用干净的接口抽象这层服务还便于替换底层实现，比如从 MySQL 迁到 Memcached。事事用事件虽有吸引力，但我的经验是额外的同步问题带来不必要的复杂性，让逻辑推理和调试变难。
guelo查看英文原文
The best practices I've seen for MVC apps isn't to put all the logic in the controllers. What you do is to create a "services" or "managers" layer that is called on by the controllers. A userService, for example, might have a function user = userService.login(name, password) It's also nice to abstract this service layer with some clean interfaces so that you can replace the underlying implementation, for example to move from MySQL to Memcached. Using events for everything has appeal but my experience is that the added synchronicity problems creates unneeded complexity and makes reasoning through the logic and debugging hard.
架构缩写被高估了，关键是分离关注点并保持简单
MVC 没问题。多年移动开发后我最大的体会是：各种架构缩写普遍被高估了。最重要的是分离关注点，就视图和状态的管理及通信达成合理共识，具体细节应从应用需求中产生，而不是自上而下套用“完美架构”。团队对每段代码必须属于缩写中哪个字母过于较真，反而给项目带来很多不必要的痛苦。VIPER 就是极端例子——发一个 HTTP 请求并在列表里显示结果不该要五个以上的文件。
skohan查看英文原文
MVC is fine. After years experience in mobile development, my main takeaway is that application architecture acronyms in general are over-rated. The most important thing is to separate concerns, and to agree on some sensible structure for managing views and state, and communicating between them. Usually the details of that should arise from the needs of the application, not come top-down from some idea about "the perfect application architecture". Aside from that, everything should just be kept as simple as possible. IMO it actually adds a lot of unnecessary pain and complication to a project when a team is too rigid about which letter of an acronym each piece of code must fit into. VIPER would be an extreme example of this. It should not take five+ separate code files to execute an HTTP request and display the results in a list view.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选