使用前端框架(Vue.js)后所带来的变化

传统MVC

典型的框架例如Rails, 数据层,控制器层,视图层。 数据是共享的,所有数据都在一个数据库中,并且在所有controller中可以方便的快速访问,如果想共享数据,还可以将其放置在顶级类中,例如ApplicationController中。

每个controller控制独立的业务逻辑,

加上前端框架以后

组件化带来的复用优势

复用性大幅度提高。HTML、JavaScript和CSS代码存在于同一个文件中,结构清晰,维护方便,复用容易。这样可以直接借用已有的一些组件库,例如element

新数据层(前端)带来新的挑战与管理复杂度

其最大的亮点在与组件化提高了js代码和view的清晰度,组织更为合理,更容易复用,但是由于其有自身的数据层,而不再直接使用后端的数据层。

这样就带来一个问题,后端有数据层,这是必须的,前端也出现一个数据层,这样对于一个应用而言,整体上就有2个数据层存在,管理成本就会增加。

成本主要体现在,组件之间的数据传递。在Vue.js中父子组件间的数据双向传递,不同组件间的传递。简单的情况可以使用event bus来实现,复杂的情况可以使用Vuex这个插件来实现,当然Vuex会带来很多的新概念,这也是维护成本和学习成本。

至于具体实现时该使用何种方式传递,就需要权衡了。

视图层可以几乎全部转移到前端浏览器

新架构下,前端和后端通过XHR通信,后端数据库只存储需要持久化的数据。页面渲染、界面交互和部分数据存储功能需要前端来承担。

界面渲染及UI交互逻辑直接通过后端生成并发送至前端,此时UI所需要的数据并没有填充,还需要异步去获取一次,前端逻辑在嵌入填充这些数据。

原来的视图层在后端通过模板语言来处理,就地将模板解释成HTML代码,再嵌入一些数据,发送到前端,前端收到后直接渲染展示。

内置数据绑定带来的便利

传统MVC的方式,可能是用jQuery发送一个xhr请求,然后处理回调,选择要改变的元素,然后再改变元素。

在vue.js中是通过v-model实现这个功能。这是比较大的一个亮点,将组件中的数据直接与view中的展示部分(可以是一个变量,也可以是一个表单input)直接绑定,当数据层变化时,view展示会自动变化更新,当用户在界面上将数据修改后,其变化也会自动传递到内部的数据层。

计算资源消耗分担到前端

原来,模板语言,相当于组件,在后端需要解释一遍,这些解释工作消耗的是后端计算资源,如今,模板解释相当于全由浏览器完成了。

数据交互方式的改变

原来的方式,如果不加特殊处理,可能是页面reload,那就是全量页面的请求,如果数据是局部更新的话,也是全量请求,这里存在的资源浪费和不必要的重加载问题,也会感觉上慢一些。

如果使用了turbolinks的话,则并不会reload,而是turbolinks帮我们在后面发出一个xhr请求,由它来对比返回的数据与当前页面,在发生变化的地方,进行替换。感觉上速度大幅度提升,体验很好。

turbolinks背后还是全量的请求(请求返回了了整个HTML页面),并不是按需的数据请求,前端框架一般只获取必要的数据,如果是前后端分离的话(例如单页应用),与后端的交互都是数据请求了(xhr),不会有reload。

当然也可以使用jQuery来发送请求实现类似的效果,然后再处理回调,回调中处理界面变化,通知用户等。

路由管理

Vue.js这样的前端框架需要自己来管理路由的切换,显示,与原来的后端处理有所不同。

鉴权带来的变化

原来的rails,可能是使用cookie来标识一个用户的登录,cookie会在每次请求被自动带到服务器端。

首屏加载时间变慢

首屏加载时间相对于纯后端,可能会变慢。有待进一步研究。

搜索引擎难以获取单页应用的内容

如果是单页应用,首页没有很多HTML代码,而是靠JavaScript来加载大部分内容,搜索引擎访问到的首页的时候,只是得到了一堆的JavaScript代码,并没有得到任何页面结构,搜索引擎也不会去解释这些JavaScript,这就导致搜索引擎不能充分得到页面结构及内容。

Resources