为什么我不再推荐使用MVC框架？

Posted 2021-05-01 java版web项目

优质文章，第一时间送达

上一篇：

下一篇：（已修复）

http://suo.im/60hN1i

标题是不是有点耸人听闻，不过我并不是标题党。考虑到谈论这类大而虚的东西（比如最好的语言）容易引起争论和被喷，所以还请诸君带着看戏而不是庭辩的心态来看待本文。

从webform过度到mvc，我曾经惊叹mvc革命性的变革。过去，在创建应用时通常会按MVC各建一个文件夹，每个文件夹就是一个模块。MVC三者的职责是这样的：

1.Controller绑定到某个路由上，接着处理请求参数，然后创建在整个请求中可见的对象，并进行一些业务逻辑上的工作。 期间会从数据库中构造Model，也有可能新建/修改Model后将它们保存入数据库。 最后，Controller会通过View响应用户的请求，或者返回重定向的报文。 基本上业务逻辑都是实现在Controller里面的。 （下文为了阐述方便，都以“业务逻辑”特指Controller中的业务逻辑）

2.每个Model往往对应数据库的一个实体。 Model类除了装数据之外，还提供了跟自己身份相关的一些方法，比如User类提供authenticate方法以用于验证密码。 Model对象通常还会负责检验构造自己的参数是否正确。

3.View负责使用给定的参数渲染模板，并作为响应返回给用户。 View一般是由该框架提供的模板语言写成。

但是用mvc做过N个项目之后，我越来越发现这种方式在某些方面有着不可忽视的弊端。尤其在现在多端共享数据的web环境，类似于MVC这样的组织方式已经显得过气了，不同的客户端需要不同的V层，很多时候pc端用v层，h5端，小程序段、App端都有自己的V层，然后数据通过Controller做成api的形式输出数据。

所以V层是否还有必要？

最近的项目中，Controller直接就是输出一个JSON数据，这么一来，传统的View的扮演的戏份还剩多少似乎，我也一直思考如何如何在我们的项目组中进行改进。

过去，View通常由三部分组成：html代码，控制流程语句，渲染时的上下文。如果提供的是JSON格式的模板，那么View的前两部分基本不需要了，只需要渲染时的上下文。可是这么一来，为什么我还需要渲染一个JSON模板，目前的前端框架vue，React可以很方便的实现数据渲染。

所以我认为目前的多终端环境下，新的划分方式如下：

• View消亡了，PC端可以回归原始的html页面。

• Model分离成两层，一层负责数据实体，另一层负责数据的访问。

• Controller分离成两层，一层负责绑定路由，另一层负责业务逻辑。

以上是我个人对mvc的看法，大家可以讨论或给出更好的方案。

说句题外话，springboot全家桶技术交流群可以加我微信，但是坑位有限哦，由于忙于工作，有时不能及时回复大家，请多包涵。

精彩推荐

   
     
     
   

    
      
      
    
 
     
 
      
1、
 
      
2、
 
      
3、
 
      
4、
 
      
5、
 
      
6、
 
      
7、
 
      
8、
 
     
 
    
   
     
     
   

点个在看少个 bug