Question

为什么我再也不使用MVC框架了

Answer 1

其实毫无争议的是，无数个API项目都是和经常变化的屏幕绑定的。你会有很多针对不同平台或终端设备的不同API，甚至Sam Newman将其总结为BFF模式，该模式建议为每个类型的设备或平台开发对应特殊的API，甚至为APP的不同版本。Netflix的Daniel Jacobson将其解释为Experience APIs，无语。

几个月以前，我开始一段思考旅程，思考为什么我们会最终变成这样，我们还能够做些什么？这段思考旅程将我引向了应用架构中最教条的模式：MVC。当我再游历了reactive响应式编程和函数编程等技术思想以后，我开始聚焦简单和业界擅长的偷偷膨胀的过程，我相信你会感兴趣我的发现。

每个屏幕都在使用的模式是MVC，也就是Mode-View-Controller，MVC在没有Web时已经被发明出来，其软件架构是很棒的，起初，厚客户端是直接和一个数据库交互访问通讯，数十年以后，使用了MVC，用于构建OmniChannel 应用。

Angular2即将发布，也许现在是重新评估MVC用途的最好时候，重新评估MVC框架为应用架构带来的价值。

90年代后期，MVC模式被Struts采用到基于Http的Web应用中，今天它是所有应用的基石。

MVC如此光彩照人，以至于react.js只能使用委婉的方式介绍它们的框架似乎偏离了MVC主流：“React is just the View in MVC”.

当我去年开始使用React时，我感觉有些非常不同之处，如果你改变某个地方的一部分数据，那么立即，而且没有视图View和模型Model之间明显的交互，整个UI就改变了，这就是说，我很失望于React的编程模型，变得孤独起来，因为从MVC角度来看，React模型将MVC分离的几个关注混淆在同一个组件中。

作为一个服务器端后端的API设计者，我得出结论，肯定没有好的办法将API调用和React前端协调在一起，精确地说，因为React只注重视图View，竟然没有MVC中的控制器Controller。

Facebook一直拒绝在框架层次弥补这个“缺憾”，React团队首先引入了Flux模式。因为对Facebook的失望， Dan Abramov甚至推荐了另外一个模式：Redux，某种程度上走上了正确方向，但是也没有提供合适方式来连接API和前端。