08/01 发表评论

平时喜欢做点小页面来玩玩,并且一直采用单页面应用(Single Page Application)的方式来进行开发。这种开发方式是在之前一年做的一个创业项目的经验和思考,一直想写篇博客来总结一下。

个人认为单页面应用的优势相当明显:

  1. 前后端职责分离,架构清晰:前端进行交互逻辑,后端负责数据处理。
  2. 前后端单独开发、单独测试。
  3. 良好的交互体验,前端进行的是局部渲染。避免了不必要的跳转和重复渲染。

当然,SPA也有它自身的缺点,例如不利于搜索引擎优化等等,这些问题也有其相应的解决方案。

下面要介绍的这种方式可以说是一种模式或者工作流,和前端使用什么框架无关,也和后端使用什么语言、数据库无关。不能说是
The Best Practice,我相信经过更多人的讨论和思考会有 A Better Practice。:)

概览

下图展示了这种模式的整个前后端及各自的主要组成:

前后端交互流程

看起来有点复杂,接下来会仔细地对上面每一个部分进行解释。看完本文,就应该能理解上图中的各部件之间的交互流程。

前端架构

把上图的前端部分单独抽出来进行研究:

前端架构

前端中大致分为四种类型的模块:

  1. components:前端 UI 组件
  2. services:前端数据缓存和操作层
  3. databus:封装一系列 Ajax 操作,和后端进行数据交互的部件
  4. common/utils:以上组件的共用部件,可复用的函数、数据等

components

component 指的是页面上的一个可复用UI交互单元,例如一个博客的评论功能:

示例图_01

我们可以把博客评论做为一个组件,这个组件有自己的结构(html),外观(css),交互逻辑(js),所以我们可以单独做一个叫
comment 的 component,由以下文件组成:

  1. comment.html
  2. comment.css
  3. comment.js

(每个 component 可以想象成一个工程,甚至可以有自己的 README、测试等)

components tree

一个 component 可以依赖另外一个 component,这时候它们是父子关系;component 之间也可以互相组合,它们就是兄弟关系。最后的结果就类似 DOM tree,component 可以组成 components tree。

例如,现在要给这个博客添加两个功能:

  1. 显示评论回复。
  2. 鼠标放到评论或者回复的用户头像上可以显示用户名片。

示例图_02

我们构建两个组件,reply 和 user-info-card。因为每个 comment 都要有自己的回复列表,所以 comment 组件是依赖于 reply 组件的,comment 和 reply 组件是嵌套关系。

而 user-info-card 可以出现在 comment 或者 reply 当中,并且为了以后让 user-info-card 复用性更强,它应该不属于任何一个组件,它和其他组件是组合关系。所以我们就得到一个简单的 componenets tree:

示例图_03

components 之间的通信

怎么可以做到鼠标放到评论和回复的用户头像上显示名片呢?这其实牵涉到组件之间是如何进行通信的问题。

最佳的方式就是使用事件机制,所有组件之间可以通过一个叫 eventbus 通用组件进行信息的交互。所以,要做到上述功能:

  1. user-info-card 可以在 eventbus 监听一个 user-info-card:show 的事件。
  2. 而当鼠标放到 comment 和 reply 组件的头像上的时候,组件可以使用 eventbus 触发 user-info-card:show 事件。

user-info-card:

var eventbus = require("eventbus")
eventbus.on("user-info-card:show", function(user) {
    // 显示用户名片
})

comment or reply:

var eventbus = require("eventbus")
$avatar.on("mouseover", function(event) {
    eventbus.emit("user-info-card:show", userData)
})

components 之间用事件进行通信的优势在于:

  1. 组件之间没有强的依赖,组件之间被解耦。
  2. 组件之间可以单独开发、单独测试。数据和事件都可以简单的进行伪造进行测试(mocking)。

总结:component 之间有嵌套和组合的关系,构成 components tree;component 之间通过事件进行信息、数据的交换。

services

component 的渲染和显示依赖于数据(model)。例如上面的评论,就会有一个评论列表的 model。

comments: [
    {user:.., content:.., createTime: ..}, 
    {user:.., content:.., createTime: ..}, 
    {user:.., content:.., createTime: ..}
]

每个评论的 component 会对应一个 comment(comments 数组中的对象)进行渲染,渲染完以后就会正确地显示在页面上。

因为可能在其他 component 中也会需要用到这些数据,所以 comment component 不会自己直接保存这些 comment model。这些
model 都会保存在 service 当中,而 component 会从 service 拿取数据。components 和 services 之间是多对多的关系:一个 component 可能会从不同的 services 中拿取数据,而一个 service 可能为多个 components 提供数据。

services 除了用于缓存数据以外,还提供一系列对数据的一些操作接口。可以提供给 components 进行操作。这样的好处在于保持了数据的一直性,假如你使用的是 MVVM 框架进行 component 的开发,对数据的操作还可以直接对多个视图产生数据绑定,当
services 中的数据变化了,多个 components 的视图也会相应地得到更新。

总结:services 是对前端数据(也就是 model)的缓存和操作。

databus

而 services 中缓存的数据是从哪里来的呢?当然也许想到的第一个方案是在 services 中直接发送 Ajax 请求去服务器中拉去数据。而这里建议不直接这样做,而是把各种和后端的 API 进行交互的接口封装到一个叫 databus 的模块当中,这里的 databus 相当于是“对后端数据进行原子操作的集合”。

如上面的 comment service 需要从后端进行拉取数据,它会这样做:

var databus = require("databus")
var comments = null
databus.getAllComments(function(cmts) { // 调用databus方法进行数据拉取
    comments = cmts
})

而 databus 中则封装了一层 Ajax:

databus.getAllCommetns = function(callback) {
    utils.ajax({
        url: "/comments",
        method: "GET",
        success: callback
    })
}

这样做是因为,不同的 services 之间可能会用到同样的接口对后端进行操作,把操作封装起来可以提高接口的复用性。注意,如果 databus 中的某些操作不涉及到 servcies 的数据,这操作也可以被 components 所调用(例如退出、登录等)。

总结:databus 封装了提供给 services 和 component 和后端 API 进行交互的接口。

common/utils

这两个模块都可以被其他组件所依赖。

common,故名思议,组件之间的共用数据和一些程序参数可以缓存在这里。

utils,封装了一些可复用的函数,例如ajax等。

eventbus

所有组件(特别是 components 之间)的通过事件机制进行数据、消息通信的接口。可以简单地使用 EventEmitter 这个库来实现。

后端架构

传统的网页页面一般都是由后端进行页面的渲染,而在我们的架构当中,后端只渲染一个页面,其后,后端只是相当于一个Web Service,前端使用Ajax调用其接口进行数据的调取和操作,使用数据进行页面的渲染。

这样的好处就是,后端不仅仅能处理 Web 端的页面的请求,而且处理提供移动端、桌面端的请求或者作为第三方开放接口来使用。大大提高后端处理请求的灵活性。

后端对比起前端的架构来说会简单很多,但是这只是其中一种模式,对于不同复杂程度的应用可能会做相应的调整。后端大概分为三层:

后端架构

  1. CGI:设置不同的路由规则,接受前端来的请求,处理数据,返回结果。
  2. business:这一层封装了对数据库的一些操作,business 可以被 CGI 所调用。
  3. database:数据库,进行数据的持久化。

例如上面的 comments 的例子,CGI 可以接收到前端发送的请求:

var commentsBusiness = require("./businesses/comments")
app.get("/comments", function(req, res) {
    // 此处调用comments的business数据库操作
    commentsBusiness.getAllComments(function(comments) {
        // 返回数据结果
        res.json(comments)
    })
})

后端的API可以采用更规范的 RESTful API 的方式,而 RESTful 不在本文的讨论范围内。有兴趣的可以参考 Best Practices for Designing a Pragmatic RESTful API

前后端的架构都基本清晰了,我们来看看文章开头的图:

前后端交互流程

看着图来,我们总结一下整个前后端的交互流程:

  1. 前端向服务端请求第一个页面,后端渲染返回。
  2. 前端加载各个 component,components 从 services 拿数据,services 通过 databus 发送 Ajax 请求向后端取数据。
  3. 后端的 CGI 接收到前端 databus 发送过来的请求,处理数据,调用 business 操作数据库,返回结果。
  4. 前端接收到后端返回的结果,把数据缓存到 service,component 拿到数据进行前端组件的渲染、显示。

工作流

一个好的工作流可以让开发事半功倍。上面的这种单页面应用也有其相应的一种开发工作流,当然这种工作流也适合非单页面应用:

  1. 进行产品功能、原型设计。
  2. 后端数据库设计。
  3. 根据产品确定前后端的 API(or RESTful API),以文档方式纪录。
  4. 前后端就可以针对 API 文档同时进行开发。
  5. 前后端最后进行连接测试。

前后端分离开发。建议都可以采用 TDD(测试驱动开发)的方式来单独测试、单独开发(关于 Web APP 测试这一块可以单独进行讨论研究),提高产品的可靠性、稳定性。

(完)

原文:https://segmentfault.com/a/1190000000607661 作者:戴嘉华

发表评论

回到顶端