1.后端为主的mvc时代

在这里插入图片描述
springmvc流程图

优点

一个很好的开发模式，降低代码的耦合，从架构上能让开发者明白代码应该写在哪里，为了让view更纯粹，可以使用thymeleaf，freemarker等模板引擎，使模板里面无法写入java代码，让前后端分工更加清晰

缺点

前端开发重度依赖开发环境，开发效率底下，这种架构下，有两种协同模式，
- 前端写demo，写好后让后端套模板，感觉像是前端写好静态页面，然后将页面交给后端，后端套成jsp，渲染数据啥的，很麻烦，套完了还需要前端确定，沟通成本挺大的
- 前端负责浏览器端的所有开发和服务器端的view层模板开发，好处是ui相关的代码都是前端写，后端不用关注，不足就是前端需要重度绑定后端环境，环境成为影响前端开发的重要因素
前端指责纠缠不清，模板引擎功能屌，依旧可以通过上下文变量来实现各种业务逻辑，只要前端弱势一些，就会被后端要求在模板层写出不少业务代码**，还有个重要的是灰色地带controller层，这个层是用来实现页面路由的，而这个页面路由本来应该是前端所关注的，但是却是由后端来实现的223**。此外controller本身也跟model纠缠不清，让人看了咬牙的业务代码经常出现controller层，坑爹。不过这些问题不能全部归于程序员的素养，不然jsp就够了223
对前端发挥的局限性，性能优化之在前端做，空间非常有限，于是经常要后端来合作，但是由于后端框架限制，很难用comet，bigpipe等技术方案来优化性能

2.基于ajax带来的spa时代

2005年-》ajax-》异步javascrip和xml被正式提出，js王者归来223（在这之前js都是在网页上贴狗皮药膏的223），于是开启了spa（single page application）单页面应用时代时代。

在这里插入图片描述

优点

前端后端分工非常清晰，前后端关键协作点是ajax接口，看起来很美妙，但是回过头看看的话这和jsp差别不大，复杂度从服务器端的jsp里面移到了浏览器的js，使得浏览器变得很复杂，类似springmvc，这个时候开始出现浏览器端的分层架构。

在这里插入图片描述

缺点

前后端接口的约定：如果后端接口一塌糊涂，或者说后端业务模型不够稳定，那么前端开发会很痛苦。不少团队也有类似尝试，通过接口规则，接口平台等方式来做，有了和后端一起沉淀的接口规则，还可以用来模拟数据，使得前后端可以在约定接口后实现高效并行开发
前端开发的复杂度控制：spa应用大多以交互型为主，js代码超过十万行很正常（草），大量的js代码组织，与view层的绑定等，都不是容易的事。

3.前端为主的mv*时代

mvc（同步通信为主）：model，view，controller
mvp（异步通讯）：model，view，presenter
mvvm（异步通信为主）：model，view，viewModel

大前端时代：后端：轻松

为了降低前端开发复杂度，涌现了大量的前端框架，比如angular js，react，vue js，ember js等，这些框架总的原则是先按模型分层，比如templates，controllers，model，然后再在层内做切分如下图：

优点

前后端职责清晰：前端工作在浏览器端，后端工作在服务器端，清晰的分工，可以让开发并行，测试数据的模拟不难，前端可以本地开发，后端则可以专注于业务逻辑的处理，输出用resful等接口
前端开发的复杂度可控：前端代码很重，但合理的分层，让前端代码能各司其职，这一块值得赞赏，简单如模板的特性选择，就有很多研究，并非越强大越好，限制什么，留下哪些自由，代码如何组织，所有的一切设计，都值得话一本书讲讲。
部署相对独立，可以快速改善产品体验

缺点

代码不能复用，比如后端依旧要对数据做各种校验，校验逻辑无法复用浏览器端的代码，如果可以复用，那么后端的数据校验相对简单化。
全异步，对seo不利，往往还要做服务器同步渲染的降级方案
性能并非最佳，特别是移动互联网的环境下
spa不能满足所有需求，依旧存在大量多页面应用程序，url design 依旧需要后端配合，前端无法完全掌控

4.node js带来的全栈时代

前端为主的MV*模式解决了很多很多问题，但如上所述，依旧存在不少不足之处。随着NodeJS的兴起，JavaScript 开始有能力运行在服务端。这意味着可以有一种新的研发模式:

在这种研发模式下，前后端的职责很清晰。对前端来说，两个UI层各司其职:

Front-end UI layer处理浏览器层的展现逻辑。通过CSS渲染样式，通过JavaScript添加交互功能，HTML的生成也可以放在这层，具体看应用场景。
Back-end UI layer处理路由、模板、数据获取、Cookie等。通过路由，前端终于可以自主把控URL Design,这样无论是单页面应用还是多页面应用，前端都可以自由调控。后端也终于可以摆脱对展现的强关注，转而可以专心于业务逻辑层的开发。

通过Node, Web Server层也是JavaScript代码，这意味着部分代码可前后复用，需要SEO
的场景可以在服务端同步渲染，于异步请求太多导致的性能问题也可以通过服务端来缓解。前一-种模
式的不足，通过这种模式几乎都能完美解决掉。
与JSP模式相比，全栈模式看起来是一种回归，也的确是-种向原始开发模式的回归，不过是一种螺旋上升式的回归。

基于NodeJS的全栈模式，依旧面临很多挑战:

要前端对服务端编程有更进一步的认识。比如TCP/IP等网络知识的掌握。
NodeJS层与Java层的高效通信。NodeJS模式下，都在服务器端，RESTful HTTP通信未必高
效，通过SOAP等方式通信更高效。一切需要在验证中前行。
对部署、运维层面的熟练了解，需要更多知识点和实操经验。
大量历史遗留问题如何过渡。这可能是最大最大的阻力。