前两天和朋友讨论，我展示了一番 d2js，朋友有点纳闷，你这个是直接操作数据库，不是违背了 MVC 设计思想吗？

经常讨论有助于刺激思维。这次本人忽然进入了状态，终于意识到问题所在！

现在的系统叠床架屋，前端有一套 mvc 框架，后端还有 mvc 框架。现在后端都进入 output json 的时代了，没想到还自有一套 mvc。

我说，前端因为和服务器隔离，在另外一个进程如浏览器进程上跑，而其又需要显示，需要 v，既然有v，便需要 mvc，所以前端必须弄一套 mvc，这是必然的。

而后端呢？

如果站在全系统视角：java web服务器，只是系统里的 c，数据库——不管sql nosql——才是真正的 m！

运行于java服务器上的数据，都不全，都是自 db 中提取的一个 snapshot 而已！ 道理与前端的 m 可以视同为 db 中的一个 snapshot 一样！

站在全系统视角，事情变得非常明了，简单就是美。我之前喜欢谈论数据库是中心，现在完全不用这套思维了。

数据库是 M，后端是 C， 前端（含放在后端的JSP/JSSP）是 V

昨天看到Java有人讨论框架太复杂，我兴奋的前去砸场子。这里是一段对话：

很多情况下V是省不掉的
虽然已经退化到一个Json实体
但是，还是独立的V啊

为啥restful的response就不能叫V了？
虽然很薄，但那也是独立于持久层的存在
哪那么容易就能从这么多种多样的持久层直接捅上来？
什么年头了，还在围着数据库转圈圈
数据库是且仅是一个持久化存储服务而已
只要HTTP还是无状态无连接为主
VO就不可能被跳过

我的观点：

no，db 这个阴影会永远笼罩在java头上，事实上，人家关系运算搞的好好的有数学基础，支持各种java无法理解的选择投影，而nosql又可以跑 mapreduce 跑大数据，只有java 一厢情愿的认为应当把数据放到内存变为 java 里的对象

没有 db 的系统根本不是系统。

而没有java可以换 php，换 c#，换 ruby，换 python，换 js

现在连个app都有 sqlite，甚至browser都有

数据永远要放在 db 里，放在java里的也必须放到 db 里，放在文件里的，也要把文件名登记在 db 里，实际上文件系统就是个大 db

db 的地位就是这么牛，db 才是当之无愧的 m

你说 rpc 的输出也能算 v，那更是可笑了，一个函数调用跨了进程垮了服务器返回值就是v，不跨进程不跨服务器返回值就是返回值，这得多荒谬啊——照这思路函数返回值在内存的布局也算成 v 好了

理解这个结构后，d2js 就顺理成章了。

这里可能有人认为数据库上既然跑 sql，sql 扮演了 c 的内容，应该将数据库也视为 c 才对。

这个问题有点类似于 tensorflow 的 graph，graph 是由 python 构建的，最终生成op码被解释执行。这里，执行是 c++ 的 dll 完成的，但是，逻辑是由 python 提供的！所以，问题根源是逻辑由谁提供。

java 提供的逻辑由数据库完成，所以 java 是 c。即使全部弄成存储过程都在 db 上运行，控制存储过程运行的是链路是“前端->后端->DB”，那么依然可以认为是由 java 和 db 共同分担了 c 的职能。

按这个思路继续，后端甚至不是唯一的 c，其应当视为与前端的 c 共同完成 controller 职能的一部分 controller。

那么，像MQ、规则引擎、流程引擎等等呢？

要理解 MVC 是界面框架，上面这些根本没有界面，谈什么 mvc 呢？它们就是服务啊。如果非要说有 v，那日志、watch board 就算是 v 好了，在这种视角它们就是 c。

Java 后端搞 MVC 是邪路