单页应用详解——（5）创建视图

单页应用详解（Single page apps in depth）
本文为译文，原文：http://singlepageappbook.com/detail1.html
5.什么是View? 看看替代方案
在这章节中，我们来看看各个框架中实现view的一些概念和区别。我写这章的时候写了一些代码来比较（基于TodoMVC）,但是决定移除它，你的代码通常也会差不多，但是底层的机制和抽象使用的不一样。

view层是当代单页应用框架中最复杂的部分。毕竟，这是整个单页应用的关键：简单的创造相当丰富有交互性的视图。正如你将看到的，一般有2种方式实现view层：一种是基于代码，另一种是基于标记和相当复杂的模板系统。这就导致了不同架构的选择。

view需要完成下面几个任务：

渲染模板，我们需要有一种方式来处理数据，并把它映射/输出到HTML。
在数据响应和change事件之后更新views。当model中的数据改变之后，需要更新相关的views，引用新的数据。
通过event handlers绑定事件到HTML。当用户触发与view中HTML元素的交互，需要一种方式来触发行为。
view层的实现期望提供一种标准的机制和惯例来完成这些任务。下面这个图标展示view是如何与models和HTML交互的：



这里有2个问题：

事件处理器如何绑定到HTML/从HTML解绑
什么样粒度的数据需要重新更新
解答了这2个问题，你就能确定view层的实现有多复杂，模板系统应该如何输出。

事件的绑定通过DOM选择，数据更新通过"view-granular"，有点像Backbone.js

在这个章节里，我会分析人们在写view层的一些选择，我做了些对比：

低交互性 vs 高交互性
近服务器端  vs  近客户端
标记驱动视图  vs 模型支持的视图
视图粒度 vs 元素粒度 vs 字符串粒度的更新
基于css vs 框架生成 的事件绑定

低交互性
vs 高交互性

低交互性 案例: Github 页面基本上是静态的. 拿到的基本上是已经处理好的页面文档，包含的基本上是静态信息，然后加一些javascript交互. 数据变化通常是整个页面刷新.	高交互性 案例: Gmail 页面基本上是动态的. 有一系列的数据，期望与用户用不同的方式交互，对数据更改要立即反应到页面上. 数据变化需要更新到视图上，但不是整个页面刷新，因为view里有很多细小的中间状态而这些状态并不存在数据库里.
状态和数据可以保存在HTML中，因为数据是已经被改变了的，页面已经被刷新了的. 大多数的状态在HTML里，UI的各个部分通常没有什么交互。. 如果需要复杂的交互通过服务器端来解决.	状态和数据保存在HTML是一种非常不好的方式，因为它会导致多个view同步引用同一份数据会非常难. HTML各部分之间可以有复杂的交互，数据是从表现中分离的. 交互行为不需要映射到服务器端的处理，

Github和Gmail都是当代的web应用，但是他们有不同的需求。Github的页面是大量的表单驱动，通过碎片的数据来触发整个页面的刷新。Gmail里的行为会触发复杂的变化：添加和触发一个新的消息来更新多个地方而不刷新这个页面。
你在做哪种类型的应用决定了选择什么样的架构/框架。

近服务器端
 vs  近客户端

UI的构建靠近服务器端跟接近数据库，数据的访问将会更早，更少的延迟。UI的构建靠近客户端可以更靠近用户，可以让响应/复杂的UI更容易开发。



待续...