1.2 传统的MVC开发模式的痛点

随着开发团队的扩大和项目架构的不断演进，传统MVC开发模式渐渐有些“力不从心”。接下来笔者结合自身的开发经历分析传统MVC开发模式的一些痛点。

痛点一：效率问题

以Java Web项目开发中的JSP技术为例。JSP必须在Servlet容器（例如Tomcat、Jetty等）中运行。在请求JSP时也需要进行一次编译过程，最后被编译成Java类和Class文件，这些都会占用JVM的内存空间，同时也需要一个新的类加载器进行加载。JSP技术与Java语言和Servlet强关联，在解耦上无法与模板引擎或纯HTML页面相媲美。另外，每次请求JSP后得到的响应都是Servlet通过输出流对象返回HTML页面，效率上没有直接使用HTML高。由于JSP与Servlet容器强关联，在项目优化时无法直接使用Nginx等吞吐量较高的Web服务器作为JSP的Web服务器，因此可供选择的优化方案不多。

痛点二：人员分工不明

MVC开发模式下的工作流程通常是设计人员提供页面原型设计后，前端工程师负责将设计图划分成HTML页面，之后由后端开发工程师将HTML页面转换为JSP页面进行逻辑处理和数据展示。在这种工作模式下，人为的出错率较高，后端开发工程师的任务更重，修改问题时需要前端工程师和后端开发工程师协同工作，效率比较低。一旦出现问题，前端工程师面对的就是充满标签和表达式的JSP，而后端开发工程师在面对样式代码或前端交互问题时，处理起来也有些吃力。

在某些紧急情况下，也会出现前端工程师调试后端代码、后端开发工程师调试前端代码的现象。分工不明确且沟通成本大，一旦某些功能需要返工，就需要前后端开发人员同时在场。这种情况对前后端人员的后期技术进步也不利，后端开发工程师追求的是高并发、高可用、高性能、安全、架构优化等，而前端工程师追求的是模块化、组件整合、速度流畅、兼容性、用户体验等。MVC开发模式显然会对这些技术人员产生影响。

痛点三：不利于项目演进

在项目初期，为了快速上线应用，使用MVC开发模式进行Java Web项目开发是非常正确的选择。此时项目的流量不大，用户量也不是很多，并不会有非常苛刻的性能问题出现。但是随着项目的不断完善，用户量和请求压力也会不断增加，对互联网项目的性能要求也会越来越高，此时的前后端模块依旧耦合在一起是非常不利于后续扩展的。

例如，为了提高负载能力，通常选择做集群分担单个应用的压力，但是模块的耦合会使得性能的优化空间越来越小，因为单个项目压力会越来越大，不进行合理的拆分就无法做到最好的优化；在发布上线的时候，明明只改了后端的代码，但是前端也需要重新发布，或者明明只改了部分页面或部分样式，后端代码也需要一起发布上线，这些都是耦合较严重时常见的不良现象。因此，原始的前后端耦合在一起的架构模式已经不能满足项目的演进方向，需要寻找一种解耦的方式替代当前的开发模式。

痛点四：无法满足业务需求

随着公司业务的不断发展，只有浏览器端的We b应用是不够的。如今，移动互联网用户数量急剧增长，手机端的原生App应用已经非常成熟，随着App软件的大量普及，越来越多的企业加入App软件开发的行列。为了尽可能地抢占商机和提升用户体验，企业不会把所有的开发资源都放在We b应用上，而是多端应用、同时开发，此时公司的业务线可能是如下几种或其中一部分：浏览器端的Web应用、iOS原生App、Android端原生App、微信小程序等。如图1-2所示是丰富的前端承载端。可能只是开发其中的一部分产品，但是除Web应用能够使用传统的MVC模式开发外，其他的都无法使用该模式进行开发，像原生App或微信小程序，前端UI和用户交互部分都有各自的技术实现，再通过调用RESTful API的方式与后端进行数据交互。

图1-2 丰富的前端承载端

这就是MVC开发模式的第四个痛点：无法满足业务需求。当然，笔者觉得MVC开发模式非常优秀，但是它也有一些不足，当业务线扩大时，仅仅只有MVC一种开发模式显然是无法让人满意的。

以上四个痛点亟待解决，这也是为什么需要前后端分离的几点原因。