《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 toutiao.com/i6763420080542843399/ 「鹅是程序猿」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

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

从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的看法,大家可以讨论或给出更好的方案。

文章目录
  1. 1. 所以V层是否还有必要?
  2. 2. 所以我认为目前的多终端环境下,新的划分方式如下: