首页-德信天下-首页

- 编辑:冯耀宗 -

广告

首页-德信天下-首页主管【38153】全程电子商务时代德信天下在全程电子商务时代之前,因为信息的传达已经没有问题,当时的物流也发展了很多年,所以想要完成电子商务的整个流程,最大的困难就是我们上一章提到的交易的信用问题。
 
 
2003年,德信天下阿里巴巴公司发布了一款可以算是电商发展过程中里程碑般的产品——支付宝。这个产品最大的意义就是解决了陌生人间交易的信用问题,支付宝通过把买家付款和卖家收款这两个事拆分开来,在中间做了一层代理。买家先把钱支付给支付宝,然后卖家发货,当货物抵达买家。在这个交易模型下,用户仅需要信任支付宝就可以完成交易,当然这个信任也不是一下就建立起来的,总会有人担心,我把钱给了支付宝,他们拿钱跑了怎么办。但经过一部分敢于信任的人的尝试,这个顾虑一点点消失,用户对支付宝的信任感也一点点增强。信任问题解决以后,整个电商流程就变得顺畅了,这样电子商务就进入了全程电子商务时代,这个时代一直持续到现在。
 
 
而随着交易流程的打通,从技术角度来说,电商系统的需求就变得复杂了,纯靠当时像ASP、JSP这些模板语言写一个交易网站,程序猿们还是很痛苦的。于是,从这样一个时间段开始,在业务的压迫下,技术也开始进入一个高速发展期。而我们前端的技术分支也开始了从无到有,再到丰富的过程。
 
 
当然,我们心里也要有一个概念,那就是技术是工具,它始终要为业务服务的。每一种技术能够发展成熟,肯定是它在业务的某个发展时期解决了一些比较重要的问题,这才能让这种技术得到认可和普及。全程电子商务时代才是前端这个技术分支发展的主要时期,下来我们聊一下这些年电商发展过程中遇到了什么问题?伴随着这些问题的解决,前端技术又都发生了什么样的变化?
 
德信天下
 
4.1 Ajax的应用
 
 
最先要说的就是Ajax的出现,在其出现的时期,这个东西绝对是web开发的一大福音。举个例子,设想一下假如没有异步通信的时候,我们填写了一个有20个输入框的表单,又一个个检查了一遍以后,终于有勇气点了一下提交按钮。但是!这时候返回的是一个错误页面,“对不起,您的名字已存在!”。这样我们就又要去重新填那20个字段了,我们还要祈祷着第二次就都能填正确。但是ajax出现后,这就大不一样了,我们大家可以随时在当前页面和后端做一个验证,来保证只要不是后端出了问题,我们提交过去的值都是合法的。
 
 
Ajax这个名称是2005年才有的,在这之前各家浏览器厂商就已经各自用自己的方式实现了异步通讯的机制,这也就有了另外一个问题,兼容性!每个浏览器对Ajax的实现都不一样,但每一个浏览器都有一定的市场占有率,这就有点难为程序猿了,尤其当时只把js当做简单的脚本语言的开发人员来说,一下子多了这么多的浏览器要去兼容,简直是灾难!这样的一个问题的解决是从两方面来进行的,第一个是在2006年,W3C终于将Ajax纳入其标准,这就从另一方面代表着以后的浏览器都要按着统一的方法来实现Ajax。但标准归标准,等标准全部实现还是需要时间的,为了解决当下的问题,就有人或组织封装了一些兼容各种Ajax实现的类库。其中最为有名的就是jQuery,它除了Ajax外,还抹平了其他例如Dom操作等方法的兼容性问题,一度成为最流行的前端类库。
 
 
 
4.2 前后端的划分和分离
 
 
Ajax的出现,也带来了另外一个问题,那就是有了Ajax以后,之前用模板语言实现起来的功能变得简单,之前模板语言实现不了的功能现在也能实现了。这样就造成慢慢的变多的逻辑转移到了javascript上,使其变得越来越复杂。
 
 
随着js复杂度的增长,原来的开发模式出现了问题,一个程序猿搞定全站变得越来越不靠谱,因此在这样一个时间段就把网站开发这个职位划分成了前端和后端两个职位。但是只划分了前后端的职责范围还是远远不够的,我们在原来的开发模式下,前后端的代码也在一起的。现在既然已经分为前后端两波人在开发了,维护同一套代码就变得不那么方便。项目越复杂,出现你等我,我等你的情况就会慢慢的变多,这样就拖慢了整体团队的节奏。所以为了团队的效率,前后端的代码也要做分离。
 
 
前后端的分离方式分为部分分离和全部分离两种,部分分离是只把脚本和样式分离出去,而html模板还留在后端通过jsp,velocity或者freemarker来渲染;另一种就是完全分离,脚本样式以及模板全都放在前端来维护。
 
 
部分分离已经很大程度上解决了前后端开发时的协调问题,开发效率也得到了很大程度的提升。但也得承认,这种方式也还是有问题的。当我们要开发html模板的时候,就需要搭起一整套后端的开发环境,或者是找后端同学来协助。
 
 
而完全分离一般有两种方案,第一种就是使用velocity这种在nodejs和java下都可以编译的页面模板,在开发时放到前端项目里,但在发布时,会把模板发布到后端的模板目录下,这样,开发时就做到了完全分离。这种方式最大的好处就是线上模板的渲染还是由java来做的,形成的是带有动态数据的html,比较有利于SEO。但这种方式下,前端的开发环境和发布系统的复杂度都相对较高,单纯的前端改动也还是要带着后端一起发布。
 
 
第二种完全分离的方式,就是把纯静态的html模板完全放在前端,数据全部通过RESTful接口来进行交互。这样前后端就完全分开了,脱离了后端的模板,而这种方式的系统复杂度也会比第一种完全分离的方式低。但这种方案下,所有的页面数据都是用js渲染的,没有动态模板,不太利于SEO。这个不足我们大家可以通过做server render或者给蜘蛛做一套定制页面来解决。
 
 
 
4.3 分层架构的出现
 
 
随着业务进一步的复杂,我们又开始考虑怎么让一个复杂系统变得可维护,这时候就体现出一个网站架构的作用了。因为后端比前端发展的要早,分层架构这个概念在后端的发展过程中就已经有了,我们最常见的就是MVC结构。这样一个时间段前端也发展到一定的程度上了,也是需要分层架构来让代码变得更加可维护。
 
 
分层设计最大的意义就是解耦,如果我们的系统中的各层之间是松散耦合的,当我们要改变其中一个层级的时候,只要保证该层级的接口不变即可,里面的实现方式可以随意变动。其他经常提到的优点,比如易维护、易复用、易扩展,其实说的也都是一个意思。在前端的分层方式上,和后端并不太一样,所以后端的MVC模式并不能完全搬到前端来。前端的分层设计在MVC的基础上又做了进一步的演进,形成了更适合前端的MVV*等方式的分层,来支持前端的逻辑。
 
 
 
4.4 模块化来了
 
 
分层架构有一定的解耦效果,但是遇到复杂业务,所有的逻辑就分成三大块显然也是不够的,并且基于javascript语言的特性,如果我们没有对全局变量做管理,变量冲突也是无法避免的。因此我们就有了模块化的处理方案。
 
 
由于前端的发展一直处于百花齐放,百家争鸣的状态, 所以在每一种技术或者方案的发展过程中基本都会出现几个分支。我们的模块化方案也未能免俗。模块化中比较有代表性的就是AMD、CMD、CommonJS和es6模块化这几种方案。
 
 
AMD 是 RequireJS 在推广过程中的规范化产出,而CMD 是 SeaJS 在推广过程中的规范化产出,这两个模块化方案有些相似,主要的区别是加载和运行的时机不太一样。这两种模块化方案是可以直接在浏览器上运行的,但也有个缺点,就是会将模块化的代码和业务代码掺杂在一起,对于强迫症的同学来说,这并不算一个很好的方案。
 
 
而随着nodejs的发展,我们有了对代码做编译的能力。这样原本不能在浏览器上运行的模块化方案,通过编译处理以后,也能正常在浏览器上跑了。这种模块化方案最具代表性的就是CommonJs的模块化方案。由于我们是要编译的,所以大部分处理模块化的代码都能够最终靠编译的过程追加进去,这样我们只用关心业务逻辑部分就可以了。当然这种方案也不是完美的,这种提前编译打包的方案会把所有引用的代码都打包进去,如果想按需加载就需要再做进一步的处理。总体来说,我还是比较倾向这种模块化方案。
 
 
在模块化方案中,还有一种被纳入标准的ES6模块化方案,理论上这种模块化方案也是可以直接运行在浏览器上的,但对浏览器的版本要求比较高。现在也有一种方案,就是通过babel编译,把ES6的语法转换成大部分浏览器可以兼容的旧版本js的语法。但这样的话,ES6的模块化相对CommonJs也就没有多大的优势了。
 

来源:,欢迎分享本文!

你会喜欢下面的文章? You'll like the following article.