文档介绍：,非常适合创业型不分前后端,经常3-5个人就可以搞定所有的开发,基本上是服务端给什么,浏览器就展现什么(由webserver层控制)好处:简单明了,本地起一个Tomcat或者Apache就能开发了,只要业务不太复杂就都还好。弊端:但业务太多了,变得复杂了,server越来越多,开发人员增多时,就会遇到以下的一些问题Service越来越多,调用关系变复杂,前端搭建本地环境不再是一件简单的事。Jsp等代码的可维护性越来越差。jsp:非常强大,可以内嵌Java代码。这种强大使得前后端的职责不清晰,jsp就变成了一个灰色地带,经常会出现为了赶项目等各种紧急的需求,会在jsp里糅杂了大量业务代码,这种积攒到一定程度,往往会打来大量的维护成本。,以后端为出发点,有了webserver层的框架升级,这就是后端的MVC时代。从上面的图可以看出来代码的维护性得到了明显的好转,MVC是个非常好的协作模式,从框架层面让开发者懂得什么是代码,应该写在什么地方,这使得模板里写不了Java代码,但功能看起来变弱了,正是这种限制使得了前后端分工更清晰,但任然会有问题存在:前端开发重度依赖开发环境这种框架下,前后协作有两种模式:一种是前端写demo,写好后让后端去套模板。好处:很明显,demo可以本地开发,很高效,不足是还要后端套模板,有可能会套错,而且还要前端确定,来回沟通调整的成本较大。另一种协作的模式是前端负责浏览器的所有开发和服务器端的view层模板开发,支付宝是这种模式。好处:UI相关的代码都是前端去写就好,后端不用太关注,弊端:前端开发严重绑定后端的环境,环境成为影响前端开发效率的重要因素。前后端职责依旧纠缠不清Velocity模板还是挺强大的,变量逻辑,宏等特性,依旧可以通过拿到上下文变量来实现各种业务逻辑。这样只要前端弱势一点,往往会被后端要求拿到的上下层写出不少业务代码,还有一个灰色地带是controller,页面路由等功能应该前端最关注的,但是由后端来实现了。三Ajax的SPA时代2005年Ajax正式提出,加上CDN开始大量用静态资源储存,于是就出现了javascriptd的SPA时代。特点:这种模式下,前后端的分工就非常清晰了,前后端的关键协作点是Ajax接口,看起开很好,但回头看看,这与jsp时代区别不大。复杂程度从服务端的jsp里移到了浏览器得到JavaScript,浏览器变得复杂,类似SpringMVC,这个时代开始出现浏览器端的分层架构:对于SPA,有几个重要的挑战前后端接口的约定:如果后端的接口一趟糊涂,后端的业务模型不够稳定,那这样前端开发会很痛苦。前端开发的复杂度调控:SPA应用大多数以功能交互型为主,JavaScript代码过十万行很正常。大量js代码的组织与view层的绑定等,都不是容易的事情。*时代为了降低前端开发的复杂度,例如:好处:前后端职责很清晰:前端在浏览器端工作,后端在服务