整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
注于Java领域优质技术，欢迎关注
作 者：Cherry300
来 源：jianshu.com/p/c86cee16b418
前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。
核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。
在互联网架构中，名词解释：
Web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。
应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。
一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。
以前的JavaWeb项目大多数都是java程序员又当爹又当妈，又搞前端，又搞后端。
随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。
大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，我建议是分开。
1、对于后端java工程师：
把精力放在java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构，弹性计算架构，微服务架构，java性能优化，以及相关的项目管理等等。
后端追求的是：三高（高并发，高可用，高性能），安全，存储，业务等等。
2、对于前端工程师：
把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等。
前端追求的是：页面表现，速度流畅，兼容性，用户体验等等。
术业有专攻，这样你的核心竞争力才会越来越高，正所谓你往生活中投入什么，生活就会反馈给你什么。并且两端的发展都越来越高深，你想什么都会，那你毕竟什么都不精。
通过将team分成前后端team，让两边的工程师更加专注各自的领域，独立治理，然后构建出一个全栈式的精益求精的team。
几曾何时，我们的JavaWeb项目都是使用了若干后台框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。
大多数项目在java后端都是分了三层，控制层，业务层，持久层。控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到jsp页面。然后jsp页面上使用各种标签或者手写java表达式将后台的数据展现出来，玩的是MVC那套思路。
我们先看这种情况：需求定完了，代码写完了，测试测完了，然后呢？要发布了吧？你需要用maven或者eclipse等工具把你的代码打成一个war包，然后把这个war包发布到你的生产环境下的web容器里，对吧？
发布完了之后，你要启动你的web容器，开始提供服务，这时候你通过配置域名，dns等等相关，你的网站就可以访问了（假设你是个网站）。那我们来看，你的前后端代码是不是全都在那个war包里？包括你的js，css，图片，各种第三方的库，对吧？
好，下面在浏览器中输入你的网站域名（www.xxx.com），之后发生了什么？（这个问题也是很多公司的面试题）我捡干的说了啊，基础不好的童鞋请自己去搜。
浏览器在通过域名通过dns服务器找到你的服务器外网ip,将http请求发送到你的服务器，在tcp3次握手之后（http下面是tcp/ip），通过tcp协议开始传输数据，你的服务器得到请求后，开始提供服务，接收参数，之后返回你的应答给浏览器，浏览器再通过content-type来解析你返回的内容，呈现给用户。
那么我们来看，我们先假设你的首页中有100张图片，此时，用户的看似一次http请求，其实并不是一次，用户在第一次访问的时候，浏览器中不会有缓存，你的100张图片，浏览器要连着请求100次http请求（有人会跟我说http长连短连的问题，不在这里讨论），你的服务器接收这些请求，都需要耗费内存去创建socket来玩tcp传输（消耗你服务器上的计四、JSP的痛点
以前的javaWeb项目大多数使用jsp作为页面层展示数据给用户，因为流量不高，因此也没有那么苛刻的性能要求，但现在是大数据时代，对于互联网项目的性能要求是越来越高，因此原始的前后端耦合在一起的架构模式已经逐渐不能满足我们，因此我们需要需找一种解耦的方式，来大幅度提升我们的负载能力。
1、动态资源和静态资源全部耦合在一起，服务器压力大，因为服务器会收到各种http请求，例如css的http请求，js的，图片的等等。一旦服务器出现状况，前后台一起玩完，用户体验极差。
2、UI出好设计图后，前端工程师只负责将设计图切成html，需要由java工程师来将html套成jsp页面，出错率较高（因为页面中经常会出现大量的js代码），修改问题时需要双方协同开发，效率低下。
3、jsp必须要在支持java的web服务器里运行（例如tomcat，jetty，resin等），无法使用nginx等（nginx据说单实例http并发高达5w，这个优势要用上），性能提不上来。
4、第一次请求jsp，必须要在web服务器中编译成servlet，第一次运行会较慢。
5、每次请求jsp都是访问servlet再用输出流输出的html页面，效率没有直接使用html高（是每次哟，亲~）。
6、jsp内有较多标签和表达式，前端工程师在修改页面时会捉襟见肘，遇到很多痛点。
7、如果jsp中的内容很多，页面响应会很慢，因为是同步加载。
8、需要前端工程师使用java的ide（例如eclipse），以及需要配置各种后端的开发环境，你们有考虑过前端工程师的感受吗。
基于上述的一些痛点，我们应该把整个项目的开发权重往前移，实现前后端真正的解耦！
以前老的方式是：
1、产品经历/领导/客户提出需求
2、UI做出设计图
3、前端工程师做html页面
4、后端工程师将html页面套成jsp页面（前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低）
5、集成出现问题
6、前端返工
7、后端返工
8、二次集成
9、集成成功
10、交付
新的方式是：
1、产品经历/领导/客户提出需求
2、UI做出设计图
3、前后端约定接口&数据&参数
4、前后端并行开发（无强依赖，可前后端并行开发，如果需求变求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）
5、前后端集成
6、前端页面调整
7、集成成功
8、交付
以前老的方式是：
1、客户端请求
2、服务端的servlet或controller接收请求（后端控制路由与渲染页面，整个项目开发的权重大部分在后端）
3、调用service,dao代码完成业务逻辑
4、返回jsp
5、jsp展现一些动态的代码
新的方式是：
1、浏览器发送请求
2、直接到达html页面（前端控制路由与渲染页面，整个项目开发的权重前移）
3、html页面负责调用服务端接口产生数据（通过ajax等等，后台返回json格式数据，json数据格式因为简洁高效而取代xml）
4、填充html，展现动态效果，在页面上进行解析并操作DOM。
总结一下新的方式的请求步骤：
大量并发浏览器请求--->web服务器集群(nginx)--->应用服务器集群(tomcat)--->文件/数据库/缓存/消息队列服务器集群
同时又可以玩分模块，还可以按业务拆成一个个的小集群，为后面的架构升级做准备。
1、可以实现真正的前后端解耦，前端服务器使用nginx。前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至你还可以css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速），前端服务器负责控制页面引用&跳转&路由，前端页面异步调用后端的接口，后端/应用服务器使用tomcat（把tomcat想象成一个数据提供者），加快整体响应速度。（这里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）
2、发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰，前端与后端是相亲相爱的一家人。
3、在大并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。（去参加阿里的技术峰会，听他们说他们的web容器都是自己写的，就算他单实例抗10万http并发，2000台是2亿http并发，并且他们还可以根据预知洪峰来无限拓展，很恐怖，就一个首页。。。）
4、减少后端服务器的并发/负载压力。除了接口以外的其他所有http请求全部转移到前端nginx上，接口的请求调用tomcat，参考nginx反向代理tomcat。且除了第一次页面请求外，浏览器会大量调用本地缓存。
5、即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。
6、也许你也需要有微信相关的轻应用，那样你的接口完全可以共用，如果也有app相关的服务，那么只要通过一些代码重构，也可以大量复用接口，提升效率。（多端应用）
7、页面显示的东西再多也不怕，因为是异步加载。
8、nginx支持页面热部署，不用重启服务器，前端升级更无缝。
9、增加代码的维护性&易读性（前后端耦在一起的代码读起来相当费劲）。
10、提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。
11、在nginx中部署证书，外网使用https访问，并且只开放443和80端口，其他端口一律关闭（防止黑客端口扫描），内网使用http，性能和安全都有保障。
12、前端大量的组件代码得以复用，组件化，提升开发效率，抽出来！
1、在开需求会议的时候，前后端工程师必须全部参加，并且需要制定好接口文档，后端工程师要写好测试用例（2个维度），不要让前端工程师充当你的专职测试，推荐使用chrome的插件postman或soapui或jmeter，service层的测试用例拿junit写。ps：前端也可以玩单元测试吗？
2、上述的接口并不是java里的interface，说白了调用接口就是调用你controler里的方法。
3、加重了前端团队的工作量，减轻了后端团队的工作量，提高了性能和可扩展性。
4、我们需要一些前端的框架来解决类似于页面嵌套，分页，页面跳转控制等功能。（上面提到的那些前端框架）。
5、如果你的项目很小，或者是一个单纯的内网项目，那你大可放心，不用任何架构而言，但是如果你的项目是外网项目，呵呵哒。
6、 以前还有人在使用类似于velocity/freemarker等模板框架来生成静态页面，仁者见仁智者见智。
7、这篇文章主要的目的是说jsp在大型外网java web项目中被淘汰掉，可没说jsp可以完全不学，对于一些学生朋友来说，jsp/servlet等相关的java web基础还是要掌握牢的，不然你以为springmvc这种框架是基于什么来写的？
8、如果页面上有一些权限等等相关的校验，那么这些相关的数据也可以通过ajax从接口里拿。
9、对于既可以前端做也可以后端做的逻辑，我建议是放到前端，为什么？因为你的逻辑需要计算资源进行计算，如果放到后端去run逻辑，则会消耗带宽&内存&cpu等等计算资源，你要记住一点就是服务端的计算资源是有限的，而如果放到前端，使用的是客户端的计算资源，这样你的服务端负载就会下降（高并发场景）。类似于数据校验这种，前后端都需要做！
10、前端需要有机制应对后端请求超时以及后端服务宕机的情况，友好的展示给用户。
1、其实对于js，css，图片这类的静态资源可以考虑放到类似于阿里云的oss这类文件服务器上（如果是普通的服务器&操作系统，存储在到达pb级的文件后，或者单个文件夹内的文件数量达到3-5万，io会有很严重的性能问题），再在oss上配cdn（全国子节点加速），这样你页面打开的速度像飞一样， 无论你在全国的哪个地方，并且你的nginx的负载会进一步降低。
2、如果你要玩轻量级微服务架构，要使用nodejs做网关，用nodejs的好处还有利于seo优化，因为nginx只是向浏览器返回页面静态资源，而国内的搜索引擎爬虫只会抓取静态数据，不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。同时因为nginx不会进行页面的组装渲染，需要把静态页面返回到浏览器，然后完成渲染工作，这加重了浏览器的渲染负担。浏览器发起的请求经过nginx进行分发，URL请求统一分发到nodejs，在nodejs中进行页面组装渲染；API请求则直接发送到后端服务器，完成响应。
3、如果遇到跨域问题，spring4的CORS可以完美解决，但一般使用nginx反向代理都不会有跨域问题，除非你把前端服务和后端服务分成两个域名。JSONP的方式也被淘汰掉了。
4、如果想玩多端应用，注意要去掉tomcat原生的session机制，要使用token机制，使用缓存（因为是分布式系统），做单点，对于token机制的安全性问题，可以搜一下jwt。
5、前端项目中可以加入mock测试（构造虚拟测试对象来模拟后端，可以独立开发和测试），后端需要有详细的测试用例，保证服务的可用性与稳定性。
前后端分离并非仅仅只是一种开发模式，而是一种架构模式（前后端分离架构）。千万不要以为只有在撸代码的时候把前端和后端分开就是前后端分离了，需要区分前后端项目。前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。
前后端工程师需要约定交互接口，实现并行开发，开发结束后需要进行独立部署，前端通过ajax来调用http请求调用后端的restful api。前端只需要关注页面的样式与动态数据的解析&渲染，而后端专注于具体业务逻辑。
4、如果想玩多端应用，注意要去掉tomcat原生的session机制，要使用token机制，使用缓存（因为是分布式系统），做单点，对于token机制的安全性问题，可以搜一下jwt。
最近无意中发现了一个巨牛的人工智能教程，忍不住分享一下给大家。教程不仅是零基础，通俗易懂，而且非常风趣幽默，像看小说一样！觉得太牛了，所以分享给大家。点下面链接可以跳转到教程。
https://www.captainbed.net/suga
知道早期的开发中，前后端是不分离的吗？那么后来它们又为什么要“分家”呢？分离后又有什么好处呢？
在前面一篇文章中，产品汪搞懂了前后端的工作分工。但是了解过程中，一个程序猿哥哥不经意间的一句话：“现在都是前后端分离的”，让小汪感到纳闷了，以前难道前后端不分离的么？于是小汪就继续深究起来。
在十几年前，前端的地位其实相对于后端并不那么强势，以下是一种经典的编程框架。
MVC：Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。
有意思的事情出现了，内容是传给用户的，前端并不是直接接触用户的！前端只是提供了个样式模板，由后端把内容嵌入进入，再由后端直接传给用户。
这个时候，前端的编程要各种顺着后端哥哥的心意，而且前端要是出bug了，还得拉上后端一起研究，谁让你往我的模板里插了内容，出了幺蛾子你就得负责到底。
这个时期前后端高度耦合，从编程环境、到开发调试，都必须“在一起”，对于前端来说，其实自主权就不高，对后端来说，也要懂一些前端的知识。
于是前端程序猿对后端程序猿说，要不……你只管你的业务和数据，把结果给我，我来负责组装与呈现，这样大家都轻松些。于是前后端就分离了。
前后端分离带来的好处：
（1）编程更轻松
前后端分离之后，后端更专注于实现业务逻辑，形成一套标准化的“API接口”，例如需要创建商品，前端将商品信息传给后端创建商品的接口，后端就会完成商品的创建，并返回创建结果。如果前端给的创建商品信息缺了标题或者价格，后端还能返回创建失败的结果，并且提示缺失了哪些信息等。
前端除了负责界面样式和交互，还接管了获取和展示数据的权利，从此前端开发就自由多了，如果遇上bug，也能很轻松定位到是前端还是后台的事情。
（2）更高的可复用性
前后端分离，更是顺应了互联网发展多样化的潮流。后端通过提供一系列可以实现不同业务功能的接口，就可以让不同的前端、甚至外部系统过来对接。
这样方便了公司不断推广自己的产品，今天推出手机网页版、明天推出APP版、后天推出小程序版本等。而后端只需要提供一次接口，无需每增加一类客户端，后端就要新写过。
用户访问网站的过程小知识：
但是久而久之，前后端分离在web网页上也遇到了一些问题，最明显的是以下两点：
前后端分离为用户设备带来的影响，可以通过“换台新手机”、“换台新电脑”解决，但是搜索引擎爬不到网页的数据，对很多重度依赖搜索引擎流量的产品来讲，打击可就大了。
例如你需要找一个菜谱的时候，可能会在百度搜索“芥蓝怎么炒好吃？”，然后再从搜索结果里面访问各种美食网站。又或者你想去哪里玩，就会在百度搜索“土耳其旅游攻略”等等。对于这类重搜索引擎流量的网站而言，如果爬虫爬不到自己的数据，客流损失就比较严重。
考虑到上诉问题，聪明的网页前端程序猿就想到了一个新的办法，那我们先把后台的数据跟HTML内容整合好，再呈现给用户吧，得力于一种叫做Node.JS的、可以使用网页前端熟悉的JavaScript编程的工具，于是有了2.0版本的前后端分离。
前端程序猿跟服务器上的后端说，让一让，给我腾个地儿，然后把Node.JS放在了服务器上。等用户或者爬虫需要访问网页时，这个运行在服务器上的程序，先请求后端获得数据，并整合到HTML中，然后再返回给用户。
这样一来，用户的设备就少了JavaScript多次请求后端的烦恼，加快了运行速度，而爬虫也可以爬取到填充好内容的HTML网页了。
看到这里，小汪就想，这么一来，用户体验、爬虫的问题确实解决了，但是让本来本该发生在用户浏览器上的事情，都在服务器上做了嘛，如果访问量大的话，咱服务器的压力不就很大了？
前端程序猿哥哥呵呵一笑，其实不然，你想想，很多用户都是在访问同一个网页，看同一个商品、读同一篇文章，这些请求，要是服务器的前端就请求后台一次，然后把整合好的HTML保存起来，下次再有人再来访问，就把这个生成好的HTML展示给用户，这样不就服务器轻松了、用户访问也快了么！
小汪又问了，那咋们页面多了，不就要每个页面都保存一份HTML文件么，服务器储存的空间不就越来越少了么？
前端程序猿哥哥继续答道：久而久之，HTML文件在服务器积累多了，就把好久都没人访问的HTML删了，给其他新保存的HTML文件让位置，通过“缓存”技术，让服务器永葆活力。
小汪恍然大悟，原来这就是缓存啊！这下子，小汪终于明白了前后端分离是什么回事，以及为什么要前后端分离。
现在随着很多大型产品的形成、独立运行，新的“信息孤岛”正在形成。例如微信的公众号-小程序-朋友圈-圈子，然后通过搜一搜进行统一搜索，内部造血，而不再依赖传统的搜索引擎为他引流。
又例如淘宝，很多年前就拒绝了让百度爬虫爬取他的商品信息，只允许在淘宝内进行搜索。你在百度上搜不到淘宝的商品，在微信上也找不淘宝的任何信息、无法访问淘宝任何的链接，如果你要淘宝购物，就只能去淘宝网站或者下载淘宝APP。新的互联网格局的形成，肯定会进一步影响着前后端的关系。
本文由 @iCheer 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
目背景
刚刚参加完一个项目，背景：后端是用java，后端服务已经开发的差不多了，现在要通过web的方式对外提供服务，也就是B/S架构。后端专注做业务逻辑，不想在后端做页面渲染的事情，只向前端提供数据接口。于是协商后打算将前后端完全分离，页面上的所有数据都通过ajax向后端取，页面渲染的事情完全由前端来做。另外还有一个紧急的情况，项目要紧急上线，整个web站点的开发时间只有两周，两周啊！于是在这样的背景下，决定开始一次前后端完全分离的尝试。
之前开发都是同步渲染和异步渲染混搭的，有些东西可以有后端PHP帮你编译好，如通用的页面模板，后端传回的页面参数等。提前预感到这次完全分离可能会遇到一些困难，但是项目上线要紧，也不能深入搞架构，于是打算就用jQuery+handlebars，jQuery来完成页面逻辑和DOM操作，用handlebars来完成页面渲染，这个方案是如此的简单粗暴，但好处能最稳妥的保证项目按期完成。其实前后端分离并不是一件容易的工作，这么做会有诸多不完善之处，后面再谈。
浅谈前后端分离
所谓的前后端分离，到底是分离什么呢？其实就是页面的渲染工作，之前是后端渲染好页面，交给前端来显示，分离后前端需要自己拼装html代码，然后再显示。前端来管理页面的渲染有很多好处，比如减少网络请求量，制作单页面应用等。事情听起来简单，但这么一分离又会牵扯到很多问题，比如：
以上每一个问题都够棘手，要处理好需要有设计精良又符合实际项目的方案。现在已经有很多框架可以帮我们做这些事情，Backbone, EmberJS, KnockoutJS, AngularJS, React, avalon等等，利用它们可以架构起一个富前端。但框架毕竟是框架，要利用到实际项目中，还是需要有自己的设计，框架并不能解决所有的问题。
之前也有看过淘宝团队的实践，利用nodejs做一个中间层，处理页面渲染、路由控制、SEO等事情，将前后端的分界线进行了重新定义。个人感觉这应该是一个正确的方向，有点颠覆的感觉，前端走向工程化，将变成真正的全栈式大前端。不知现在这种架构是否在淘宝全面铺开，真有点期待看看效果。
以上的框架，还有淘宝的实践，毕竟都是大牛之作，我这个小辈也只是参考学习过，未能在实际项目中使用。低头看看自己现在手头的项目，1个前端，2周时间，要完成一个完整的web项目，还是用最稳妥最低级的方式来搞吧~
基本结构
项目整体并不是一个单页应用，但有些模块需要做成局部的单页操作，像这种需要分步完成的操作，只需局部加载子页面即可。
因此，一个模块有一个主html页面，初始只有一些基本的骨架，有一个名字相同的js文件，该模块逻辑都在此js文件中，有一个名字相同的css文件，该模块的所有样式都定义在此css文件中。
需要异步加载的子页面，像上图中每个步骤的页面，我都使用jQuery的$.load()方法来加载，此方法能在页面某个容器中加载内容，并可指定回调函数，使用起来很方便。被异步加载的子页面我都用_开头，如_step1.html，用于做区分。
为了确保浏览器的前进后退按钮可用，我使用了hash来做路由标记，页面地址如：publish.html#step2。有个缺陷是hash并不会发送给服务器，所以SEO就废了。事实上使用history API也可以更优雅的解决问题，但需要考虑兼容性，还有额外工作要做，考虑时间因素，退而求其次，况且本项目也无需做SEO。或者像淘宝的方案那样，nodejs层与浏览器层统一路由，SEO问题可以迎刃而解。但又明显不在本人的实力范围之内，汗--！
除了用$.load异步加载的子页面，剩余的局部页面就是用handlebars提供的模板渲染了，我使用了handlebars的预编译功能，不得不说很强大，一来节约了页面加载阶段所需的编译时间（编译handlebars模板），二来编译后的模板（js文件）方便复用。
接下来就是前端逻辑如何组织，因为没有用mv*框架，所以只能靠自己来写一个便于开发的结构。如上面所述，每个模块有一个主js文件，文件内容结构如下：
var publish = {
//该模块初始化入口
init : function(){
this.renderData(param);
this.initListeners();
},
//内部所用的函数
renderData : function(param){
//渲染数据。。
},
//统一绑定监听器
initListeners : function(){
$(document.body).delegates({
'.btn' : function(){
//点击事件
},
'.btn2' : function(){
//点击事件2
},
'.checkbox' : {
'change' : function(){
//change事件
}
}
});
}
}
每个模块给一个命名空间，所有的方法都挂在上面，js文件中只做函数的定义，不立即执行任何东西，然后在html文件中调用入口方法:publish.init()。业务逻辑都封装到函数中，如上面的renderData，然后供其他地方调用。页面的事件监听器统一都注册在body元素上，用事件代理来完成，为了避免写太多的on、click之类代码，为jQuery扩展了一个delegates方法，用来以配置的方式统一绑定监听器，用法如上所示。把delegates定义的代码也放出来吧：
//以配置的方式代理事件
$.fn.delegates = function(configs) {
el = $(this[0]);
for (var name in configs) {
var value = configs[name];
if (typeof value == 'function') {
var obj = {};
obj.click = value;
value = obj;
};
for (var type in value) {
el.delegate(name, type, value[type]);
}
}
return this;
}
基本的结构就是这样，没有什么新技术，只是把现有的东西做了一下组合。但工作到此还远远没有结束，在实际应用中还会有一些东西需要处理，下面来详细说说：
公共头部底部的引用
这是一个比较棘手的问题，一般通用的头部和底部会放一些公共的代码，如页面外层结构html代码，站点使用的库如jQuery、handlebars，站点通用js和css文件。在传统的开发中，通常是写一个单独的文件如head.html，在其他页面中用后端代码如include语句引入，由此来进行复用。
现在前后端分离后，无法依靠后端来给你渲染，所以得在前端做了。既然用了handlebars，很容易想到把公用部分写成一个模板，然后预编译出来，生成一个header.js文件，然后在其他页面引用。然而在实际操作中发现了一个问题，handlebars是静态模板，编译后生成的字符串通过innerHTML的方式插入到页面，在一般的模板中这样是没问题的。现在有个问题是header中有一些<script>标签，外链着要使用的库，通过innerHTML插入<scirpt>标签，浏览器并不会发送请求加载对应的js文件，所以就出问题了。
搜索、尝试了多种方法后，最终的方案定为：用document.write()将编译结果写到页面，这样<script>标签能够正常加载。所以每个页面使用头部的代码就变成这样：
<script src="static/js/tpl/head.js"></script> <div id="header"> <script src="static/js/includeHead.js"></script> </div>
includeHead.js中的代码如下：
function includeHead(){
var header = document.getElementById('header');
var compileHead = Handlebars.templates['head'];
var head = compileHead({});
document.write(head);
}
includeHead();
看着是有点别扭，不过为了实现功能，目前也就只能这样了。
虽然用原生的innerHTML无法加载<script>标签中的内容，但是jQuery的$().html()方法进行了优化，可以查找到<script>标签并且执行里面的代码，所以用$().html()是可以完成上面的工作的。
这么一看，这个蹩脚的方案就可以替换了。
路由控制
如上面所述，jQuery的$.load()方法可以满足加载子页面的需求，现在需要解决的问题是，不管用户刷新页面还是前进后退，我们都得根据hash值来渲染对应的视图，其实就是路由控制。这个时候就需要监听hashchange事件了，我定义了一个loadPage方法用来加载子页面，然后绑定监听器如下：
window.onhashchange = this.loadPage;
在loadPage方法中，根据hash的值来调用$.load()方法，子页面的初始化工作，在$.load()的回调函数中指定。
这样做还有一个便捷之处，我们切换视图不必手动调loadPage方法，只需要修改页面的hash就可以了，hash发生变化被监听到，自动加载对应的子页面。例如，点击下一步进入步骤二：
'.next' : function(){
location.href = '#step2';
}
如此便实现了一个简单的路由控制，由于不是整站单页面，也没有多级路由，这样完全可以满足需求。至于SEO，就只能呵呵了，正好项目也不需要做SEO，否则此方法得作罢。
另外想说的一点就是页面的缓存，异步加载来的内容可以存在localStorage中，也可以放在页面上进行显隐控制，这样用户在频繁切换视图的时候无需再次请求，回到上一步的时候之前填好的表单数据也不会消失，体验会非常好。
页面间参数传递
有时候我们需要给访问的页面传参数，比如访问一个设备的详细信息页，要把设备id给传过去，detail.html?id=1，这样detail页面可以根据id去请求对应的数据。传统由后端渲染的页面，url中的参数会发送到服务端，服务端接收后可以再渲染到页面上供js使用。我们现在不行了，请求页面压根不跟后端打交道，但这个参数是必不可少的，所以需要前端有一套传递参数的机制。
其实非常简单，通过location.href可以拿到当前的url地址，然后进行字符串匹配，把参数提取出来就可以了。看上去挺土鳖的，但工作起来良好，另外也有考虑过用cookie来传递，感觉有点麻烦。
由于这些参数通常是写在<a>标签上的，而<a>标签又是根据动态数据渲染出来的（因为是动态参数），我们不可能在页面渲染完后，用js修改所有<a>标签的href值，给它追加一个参数。怎么办呢？这时候handlebars就派上用场了，我们可以使用handlebars万能的helper，在渲染页面的时候直接查询url中的参数，然后输出在编译好的代码中。我在handlebars中注册了一个helper，如下：
Handlebars.registerHelper('param', function(key, options){
var url = location.href.replace(/^[^?=]*\?/ig, '').split('#')[0];
var json = {};
url.replace(/(^|&)([^&=]+)=([^&]*)/g, function (a, b, key , value){
try {
key = decodeURIComponent(key);
} catch(e) {}
try {
value = decodeURIComponent(value);
} catch(e) {}
if (!(key in json)) {
json[key] = /\[\]$/.test(key) ? [value] : value;
}
else if (json[key] instanceof Array) {
json[key].push(value);
}
else {
json[key] = [json[key], value];
}
});
return key ? json[key] : json;
});
这个名为param的helper可以输出你所要查询的参数值，然后可以直接写在模板中，如：
<a href="detail.html?id={{param id}}">设备详细信息</a>
这样就方便多了！但是这么做有没有问题呢？其实是有些不完美的，如果你考虑“性能”二字的话。一个url中参数的值是固定的，而你每次使用这个helper都会计算一遍，白白做了多余的事情。如果handlebars可以在模板中定义常量就好了，可惜我找遍文档没发现有这个功能。只能为了方便牺牲性能了，也正印证了我标题中所说的“简单粗暴”，呵呵。
数据的校验和处理
由于数据是由后端传来的，有很多不确定性，数据可能不合法，或者结构有错，或者直接是空的。因此前端有必要对数据做一个合法性的校验。借助handlebars，可以很方便的进行数据校验。没错，就是利用helper。handlebars内置的helper如if、each都支持else语句，出错信息可以在else中输出。如果需要个性化的校验，我们可以自己定义helper来完成，关于如何自定义helper，我之前研究了下，写过一篇文章：http://www.cnblogs.com/lvdabao/p/handlebars_helper.html。总之自定义helper很强大，可以完成你所需的任何逻辑。
数据的格式化，如日期、数字等，也可以通过helper来完成。
另外一方面，前端还应对数据进行html转义，避免xss，由于handlebars已经给做了html转义，所以我们可以直接忽略此项了。
总结
本文是我刚刚参加完一个项目后所写，记录一下整个过程遇到的问题及处理方式，其他的一些细碎点如表单异步提交什么的，不是本文重点，不写了。这是我第一次实践前后端完全分离的项目，整个前端全由我来设计、开发。2周时间，凭着这套方案，项目按期开发完成，而且还提前完成了，预留出一天多的时间测试了一遍。
虽然开发任务是完成了，但是回头看一下整个方案，并不是很优雅也没有什么技术含量，文章开头提到的几个问题都没有解决。所以命题为简单粗暴的方案，都是为了赶工期啊。
最后，如果给我再来一次的机会，并且时间充足，我一定要尝试用mv*方案来搞一下，或angular，或avalon。
*请认真填写需求信息，我们会在24小时内与您取得联系。
