一种SPA单页面应用架构Word格式.docx

1、 看起来有点复杂，接下来会仔细地对上面每一个部分进行解 释。看完本文，就应该能理解上图中的各部件之间的交互流 程。前端架构 把上图的前端部分单独抽出来进行研究：前端中大致分为四种类型的模块：components ： 前端 UI 组件services ：前端数据缓存和操作层databus ：封装一系列 Ajax 操作，和后端进行数据交互的部common/utils ：以上组件的共用部件，可复用的函数、数据components个博客的评论功能：我们可以把博客评论做为一个组件，这个组件有自己的结构（html）,外观（css ）,交互逻辑（js）,所以我们可以单独 做一个叫 comment 的 com

2、ponent ，由以下文件组成：comment.html comment.css comment.js每个 component 可以想象成一个工程， 甚至可以有自己的README 、测试等）components tree个 component 可以依赖另外一个 component ，这时候它 们是父子关系； component 之间也可以互相组合， 它们就是 兄弟关系。最后的结果就类似 DOM tree ， component 可以 组成 components tree 。例如，现在要给这个博客添加两个功能： 显示评论回复。鼠标放到评论或者回复的用户头像上可以显示用户名片。我们构建两个组件，

3、reply 和 user-info-card 。因为每个comment 都要有自己的回复列表，所以 comment 组件是依 赖于 reply 组件的， comment 和 reply 组件是嵌套关系。而 user-info-card 可以出现在 comment 或者 reply 当中，并 且为了以后让 user-info-card 复用性更强，它应该不属于任 何一个组件，它和其他组件是组合关系。所以我们就得到 个简单的 componenets tree ：components 之间的通信 怎么可以做到鼠标放到评论和回复的用户头像上显示名片 呢？这其实牵涉到组件之间是如何进行通信的问题。最佳的

4、方式就是使用事件机制，所有组件之间可以通过一个 叫 eventbus 通用组件进行信息的交互。所以，要做到上述 功能：user-info-card 可以在 eventbus 监听一个user-info-card:show 的事件。而当鼠标放到 comment 和 reply 组件的头像上的时候， 组件 可以使用 eventbus 触发 user-info-card:show 事件。/var eventbus = require（eventbus） eventbus.on（show, function（user） 显示用户名片 ） comment or reply: var eventbus =

5、 require（）$avatar.on（mouseover, function（event） eventbus.emit（, userData） components 之间用事件进行通信的优势在于： 组件之间没有强的依赖，组件之间被解耦。组件之间可以单独开发、单独测试。数据和事件都可以简单 的进行伪造进行测试（ mocking ）。总结： component 之间有嵌套和组合的关系，构成components tree ； component 之间通过事件进行信息、数 据的交换。services component 的渲染和显示依赖于数据 （ model ）。例如上面的 评论，就会有一个评论列

6、表的 model 。comments: user:., content:., createTime: ., user: ., .每个评论的 component 会对应一个 comment （ comments数组中的对象）进行渲染，渲染完以后就会正确地显示在页面上。comment component 不会自己直接保存这些 comment model 。这些 model 都会保存在 service 当中，而 component会从 service 拿取数据。 components 和 services 之间是多 对多的关系：一个 component 可能会从不同的 services 中 拿取数据

7、，而一个 service 可能为多个 components 提供数 据。services 除了用于缓存数据以外，还提供一系列对数据的 些操作接口。可以提供给 components 进行操作。这样的好 处在于保持了数据的一直性，假如你使用的是 MVVM 框架进行 component 的开发，对数据的操作还可以直接对多个视components 的视图也会相应地得到更新。 services 是对前端数据（也就是 model ）的缓存和操 作。databus拉去数据。而这里建议不直接这样做，而是把各种和后端的API 进行交互的接口封装到一个叫 databus 的模块当中，这 里的 databus 相当

8、于是“对后端数据进行原子操作的集合”。如上面的 comment service 需要从后端进行拉取数据，它会 这样做：调用var databus = require（databus）var comments = nulldatabus.getAllComments（function（cmts） / databus 方法进行数据拉取comments = cmts）databus.getAllCommetns = function（callback） utils.ajax（url: /comments, method:GET, success: callback这样做是因为， 不同的 servic

9、es 之间可能会用到同样的接口对后端进行操作，把操作封装起来可以提高接口的复用性。这操作也可以被 components 所调用（例如退出、登录等） 总结：databus 封装了提供给 services 和 component 和后端API 进行交互的接口。common/utils这两个模块都可以被其他组件所依赖。common ，故名思议，组件之间的共用数据和一些程序参数 可以缓存在这里。utils ，封装了一些可复用的函数，例如 ajax 等。eventbus所有组件（特别是 components 之间）的通过事件机制进行 数据、 消息通信的接口。 可以简单地使用 EventEmitter 这

10、个 库来实现。后端架构 传统的网页页面一般都是由后端进行页面的渲染，而在我们 的架构当中，后端只渲染一个页面，其后，后端只是相当于个 Web Service ，前端使用 Ajax 调用其接口进行数据的调取和操作，使用数据进行页面的渲染。这样的好处就是， 后端不仅仅能处理 Web 端的页面的请求， 而且处理提供移动端、桌面端的请求或者作为第三方开放接 口来使用。大大提高后端处理请求的灵活性。后端对比起前端的架构来说会简单很多，但是这只是其中 种模式，对于不同复杂程度的应用可能会做相应的调整。后端大概分为三层：CGI ：设置不同的路由规则， 接受前端来的请求， 处理数据， 返回结果。busines

11、s ：这一层封装了对数据库的一些操作， business 可 以被 CGI 所调用。database ：数据库，进行数据的持久化。例如上面的 comments 的例子， CGI 可以接收到前端发送的 请求：var commentsBusiness =/ 此处调用require（./businesses/comments） app.get（, function（req, res） comments 的 business 数据库操作commentsBusiness.getAllComments（function（comments）/ 返回数据结果res.json（comments）后端的API 可

12、以采用更规范的 RESTful API 的方式，而RESTful 不在本文的讨论范围内。有兴趣的可以参考 BestPractices for Designing a Pragmatic RESTful API前后端的架构都基本清晰了，我们来看看文章开头的图： 看着图来，我们总结一下整个前后端的交互流程： 前端向服务端请求第一个页面，后端渲染返回。前端加载各个 component ，components 从 services 拿数据，services 通过 databus 发送 Ajax 请求向后端取数据。后端的 CGI 接收到前端 databus 发送过来的请求， 处理数据， 调用 busin

13、ess 操作数据库，返回结果。前端接收到后端返回的结果，把数据缓存到 service ，component 拿到数据进行前端组件的渲染、显示。工作流个好的工作流可以让开发事半功倍。上面的这种单页面应 用也有其相应的一种开发工作流，当然这种工作流也适合非 单页面应用：进行产品功能、原型设计。后端数据库设计。根据产品确定前后端的 API （or RESTful API ），以文档方式纪录。前后端就可以针对 API 文档同时进行开发。前后端最后进行连接测试。前后端分离开发。建议都可以采用TDD （测试驱动开发）的方式来单独测试、单独开发（关于Web APP 测试这一块可以单独进行讨论研究） ，提高产品的可靠性、稳定性。完）