Backbone之View的理解

<1>vew是backbone的一个核心组件，也是mvc中的v，可见其在框架中的重要性。个人感觉，在后台mvc框架中，如struts，express等，核心或者说工作量大的是在C部分，也就是是逻辑与业务处理。
而在前端MVC中，个人觉得核心是在VIEW部分，在Backbone中，实现了页面分离，为后面的数据绑定无疑添加了太多的方面，从而优化了整个前端量；接下来，我们可以看下VIEW的构造：

一个VIEW组件的构造是通过Backbone.View的extend方法，来定义一个视图；如下：

你可以看见里面有个render()方法，一般render()方法是操作视图显示的内容；所以，我们可以实例化TestView，在调用render()方法即可；

还存在另一种方法，即initialize()，如果视图内部有该函数时，当我们实例化该视图类时，会自动执行。

这时只要实例化对象即可执行。
this.$el.html(tmpl(data));
<2>我们知道后端MVC框架一般都有对前端实现抽象的具体模板，方便数据的绑定与交互。在Backbone中，依靠underscore库也实现了相应的功能，即实现了_.template函数。

<3>events属性：
我们知道前端页面很大一部分是基于事件的，如何优化绑定事件，从而优化整体性能一直是前端框架的核心点之一；在JQuery库中，我们操作的页面对象流是整个document，我们通过$('#id')根据id获取元素，$('.class')根据样式类名选择元素，$('tag')根据标签名选择元素，还有其他选择器，这些选择器无一例外都是在html的DOM树上寻的元素，在添加事件。然而这种方式的缺点也是显而易见的，当这个DOM树比较复杂时，选择器浏览dom树的代价也会变大，所以若能将dom树 的规模下降后进行选择，就能优化性能，这点有点像算法里的归并排序，将一个大规模的问题分成几个小规模但类型一样的问题进行解决。其次，在juqery中，有时一个元素有多种选择方式，基于不同选择器的事件可能会有所重叠，冲突，导致代码量大不好维护，影响二次开发。
下面是在Backbone中定义的事件，

上述的结构是否较为清楚，当一个页面数据交互比较少时，确实无论jquery，backbone都能完成的相对较好。但是，当数据交互量大时，这时backbone就能体现出十分好的性能，所以backbone常常用作单页面富表现化的框架。常常用jquery的人突然转用backbone来构造一个数据交互相对大的系统时，内心往往是激动不平的，我就是那种。


下面来介绍一个listento函数，这个函数跟jquery里的addlistener函数类似：
当它还有个比较好用的功能，就是不止监视dom对象的改变，还能监视数据层的变化，即model层的改变来回调函数；
如下：

这个具体怎么理解呢？我们知道，数据库的概念中有个叫“脏数据”的概念，指的是数据的变化并为及时更新因而收到处于之前状态的数据。
你可以想象一个场景，当两个view都用到一个model，一个view给这个model做了一些改变，另一个view该如何，是接受它改变后的状态呢，还是拒绝它的改变，当然这得看具体的业务场景。所以在前端MVC中，对数据的操作也是非常重要的。