Web技术的前世此生（三）

前言：我是JavaScript，若是你还不认识我，不妨先看看《 Web技术的前世此生（一）》，以及《 Web技术的前世此生（二）》

前面我提过，个人大哥HTML有一个叫PHP的死党，这家伙有事没事常常上咱们家串门。

这天，PHP又来找我大哥闲扯。

“老哥，你知道一个叫Ruby的家伙吗？”PHP问道。

“知道啊，最近咱们合做过好几个项目呢。怎么想起问它了？”

“呀，你是不清楚，这小子最近在咱们那可火了，据说是鼓捣了一个什么架子。”PHP继续说道。

“喔，你是说Rails啊，”很明显，大哥对PHP口中的“架子”很熟悉，向PHP解释道：“那不是架子，是Ruby用来构建网站的框架。”

我在一旁听着，借机打趣道：“后端那帮家伙有一个算一个，谁敢说开发网站有比咱PHP老兄还火的？”

“Js，你可别小看了这个Rails，”大哥做为一个老实人，听不出我在开玩笑，继续一本正经的说：“以前PHP老弟的平易近人对客户是挺有吸引力的，然而随着他们的网站规模愈来愈大，PHP的亲和力对于他们而言反而成了一种难以驾驭的负担，彷佛他们更须要寻求的是一种约束。”

“哎呀，老哥，你说的太对了，”PHP忽然从凳子上跳起来，“最近好几个老客户都从我这撤了，据说跑去找Ruby那小子了。老哥你说，那小子到底是有什么魔力？”

“它搞的Rails框架就是用来规范网站的开发行为，明确你我之间的职责所在的。”大哥慢条斯理地说道。

“大哥，您就别卖关子了，赶忙给咱们讲讲这个Rails吧？”对这事我也来了兴致。

“它对一个网站的架构划分了三个层次。好比我就归属于只负责页面展示的视图层（View）；有关业务逻辑的活从视图层剥离出来，由不一样的模型（Model）去作；至于接受用户的输入交由恰当的Model去处理，处理完后再将数据传递给View，这个由控制器（controller）完成。”

大哥看着我迷茫的眼神，又继续补充道：“对于一个动态网站而言，每个页面应该长成什么样子是一件事，而究竟该呈现哪个页面，以及页面上动态变化的数据该是什么又是另一件事。按以前PHP的作法，一个文件中既有咱们前端用来布局页面的代码，又混杂着它用来处理业务逻辑的代码，先不说设计上是否合理，首先这就得要求使用者既要熟悉咱们前端，还要熟悉后端，”大哥一边解释着一边朝我诡秘的一笑：“Js，你有兴趣了解下PHP每次上工都是如何干活的吗？”

”别别别，”我赶忙摇头，“每次我连本身的活都干不完，哪有工夫搭理它啊。”

PHP在一旁听着不乐意了，”去你的，我还烦你老在我眼前晃悠呢。“

“这就对了！Rails的出现就解决了这个问题，咱们前端的工做就只是套用所谓的模板引擎来作页面的展示，管它Ruby操做数据库也好、作逻辑运算也罢，都通通和我们无关，咱们只须要拿到它最终处理过的数据填充到模板引擎里，再给客户展现出来就好了。”

“呃⋯⋯老哥，你这说的是否是所谓的MVC模式啊？我听个人Java老大提起过。”PHP问道。

“没错，就是MVC，Java很早之前就玩这个了，它有一个相似的框架叫structs，只是以前这种开发模式还不流行，最近被Rails炒起来了。对了，我听Java说它的structs也要升级到二代了，估计出来也会火一把吧。“

“哈哈，PHP，看来大家后端的小伙伴们都在搞框架，就你落伍了哦⋯⋯”，我又开始拿PHP开涮，“诶？PHP这家伙人呢？PHP⋯⋯”转过头才发现它已经跑出很远了，看来用不了多久关于PHP的MVC框架也会问世了。

（猿知原味注：随着Ruby on Rails的流行，2007年以后的五年，进入到了Web后端发展史上一段框架横飞的年代。框架的做用除了上面提到的展示层和业务逻辑层的解耦，还提供了诸如经过对象操做数据库的ORM技术，以及URI路由、表单验证、国际化、安全防御等网站开发中的经常使用功能。在这期间也出现了一大批优秀的Web框架，譬如SSH（Struts+Spring+Hibernate）、SpringMVC、Rails、ASP.NET MVC、Django、Flask、CodeIgniter、Yii、Lavarel、Beego⋯⋯并且还远远不止这些。）

时间来到了2010年，在那先后发生了两件事让我印象深入。

一是咱们的不少客户开始把本来在Web上提供的服务同时搬到智能手机上去，然而移动应用并不认识后端返回的Web页面（猿知原味注：关于这一点，不包括近几年兴起的Web App和Hybrid App），这就迫使哪怕业务彻底相同的应用，针对Web端和移动端也得去开发并维护两套后端代码。

二是贪婪的人类对在后端的View层渲染页面仍是不满意，他们以为咱们前端就不应和后端掺和到一块去，但愿将咱们完全分开。

之因此这两件事让我记忆犹新，是由于最终解决它们是我起了大做用。还记得我异步刷新网页的能力吗（Ajax）？既然人类讨厌在后端作页面渲染，那彻底能够经过Ajax将数据拿到前端来渲染。这样一来，一方面作到了先后端分离，纠结的人类没必要再为该由谁负责模板引擎而苦恼了；另外一方面，咱们前端和移动端一致决定让一个叫JSON的家伙当咱们的联合运输大队长，由它来负责后端数据的传输工做，这样对于相同的业务，后端只须要维护一套代码就够了。

“With great power comes great responsibility”，彼得叔叔对蜘蛛侠说的一句话让我感同身受。自从我把页面渲染的活揽到前端来以后，后端那帮哥们算是解脱了，然而我肩上的担子迅速变沉了，天天忙的不可开交。

这种状况持续了一两年，直到有一天，个人好大哥提醒了我。

“Js，你看啊，不少年前咱们前端的职责就只是作页面的展现，但Web发展到今天，咱们也和数据打上了交道。你这边不只要发数据、收数据，还要处理数据，最后还要经过操做dom将数据更新到页面上。”

HTML大哥接着说：“你是否是加粗文字能够借鉴当初后端那帮小子搞的MVC框架，也鼓捣个什么框架出来，方便我们前端将数据的活和视图的活分开来干？”

我一拍大腿，“对啊！如今的情况确实太凌乱了。咱们也能够搞个View层只负责页面渲染，搞个Model层专门处理数据模型，”我想了想接着说：“再经过某种方式将这两层关联起来，Model数据改变的时候同步到View显示出来，View上的改变也能将数据同步回Model。”

“你说的这不就是双向绑定嘛，”大哥给个人设想下了个定义，“还记得咱们有个叫Microsoft的客户吗？它在数据绑定这一块颇有经验，你能够去找它讨教讨教。”

（猿知原味注：MVVM模式最先就是被微软的WPF和Silverlight的架构师John Gossman提出来的）

没过多久，像AngularJS、KnockoutJS、EmberJs、VueJS等一系列MV*模式的前端框架就相继出现了。自此，我又过上了轻松愉快的美好生活。

故事读完了，仍是意犹未尽？不要紧，关注“猿知原味”公众号（yz--yw），还有一大波生动有趣的干货等着你。

传送门：《Web技术的前世此生（一）》《Web技术的前世此生（二）》