现在我们能够很容易的判断被选中的项目，并且我们没有必要通过对象模型去判断。这种模式对于存储无用的数据是非常有用的以至于 你可能非常想要去跟踪；请记住你能够创建一个模型并且没有必要去关联于他们存储的一些无用的图像数据。
var View = Backbone.View.extend({ initialize: function(options) { // Re-render when the model changes this.model.on('change:items', this.render, this); }, template: _.template($('#list-template').html()), events: { "#items li a": "setSelectedItem" }, render: function() { $(this.el).html(this.template(this.model.toJSON())); }, setSelectedItem: function(event) { var selectedItem = $(event.currentTarget); // Set all of the items to not have the selected class $('#items li a').removeClass('selected'); selectedItem.addClass('selected'); // Store a reference to what item was selected this.selectedItemId = selectedItem.data('id')); return false; } });
现在我们可以很容易的确定哪些项已经被选中，并且我们没有必要通过这些对象模型来了解。这个模式对于存储无用的数据是非常有用的，请记住,您可以创建不一定有端点相关联的存储无关的视图数据的模型和集合。
这种模式的缺点是你存储了无用的数据在你的模型或者集合中，它们不能真正意义上的追随一个平静的架构是因为它们不会完美的去映射在web资源上；另外，这个模式会引起一些很膨胀的在你的模型中；；并且当你保存你的模型的时候如果你的端点严格的只接受JSON数据它会引起一个很大的烦恼。
你可能会问你自己，“我如何确定我是否应该讲把额外的数据放进视图或者是模型中？”。如果额外的属性你将要增加的是围绕性的呈现，例如一个容器的高度，我们应该要添加它的图形。如果这个属性跟底层的数据模型有一些关系，然后你想要将它放进这个模型中。例如，如果上面的例子更多的显露出，因为某些原因我仅仅只希望用户通过从模型返回的项目列表中选择一个特殊的项,我可能会增加这种逻辑模型。总而言之，大多数的事情，它实际上取决于这种依赖。你能够为保持你的模型而辩论并且你可以认为保持你的观点是可能的并且把尽可能多的逻辑放进你的模型中。
渲染部分视图,而不是整个视图
当你第一次开始开发Backbone.js应用时，典型的视图结构是像这样的：
var View = Backbone.View.extend({ initialize: function(options) { this.model.on('change', this.render, this); }, template: _.template($(‘#template').html()), render: function() { this.$el.html(template(this.model.toJSON()); $(‘#a', this.$el).html(this.model.get(‘a')); $(‘#b', this.$el).html(this.model.get(‘b')); } });
在这里，任何对模型的改变都会触发对视图的一个全面的重新渲染。我第一次用Backbone.js开发时，我是这个模式的实践者。但随着视图代码的增长，我迅速的意识到，这种方法不利于维护或优化，因为当模型的任何一个属性发生变化时，视图将会完全的重新渲染。
当我遇到这个问题，我迅速的用Google搜索了一下，看看别人是怎么做的，结果找到了Ian Storm Taylor的博客，“分解你的Backbone.js渲染方法”，他在其中描述了在模型中监听单独的属性变化，然后仅仅重新渲染相对于变化属性的视图部分。Taylor也描述了返回对象的引用，以便单独的渲染函数可以很容易的链接在一起。上面的例子现在现在就变得更易于维护，性能更优。因为我们仅仅更新了模型变化的属性相对应的视图部分。
var View = Backbone.View.extend({ initialize: function(options) { this.model.on('change:a', this.renderA, this); this.model.on('change:b', this.renderB, this); }, renderA: function() { $(‘#a', this.$el).html(this.model.get(‘a')); return this; }, renderB: function() { $(‘#b', this.$el).html(this.model.get(‘b')); return this; }, render: function() { this .renderA() .renderB(); } });
我应该说一下有许多插件，比如Backbone.StickIt和Backbone.ModelBinder，提供了模型属性与视图元素的键-值绑定，这会让你省去编写许多样板代码，如果你具有复杂的表单字段检验一下它们。
保持模型与视图无关
正如 Jeremy Ashkenas 在 Backbone.js的 GitHub问题 之一中所指出的，Backbone.js 并没有实施数据与视图层之间关注点的任何真正分离，除非模型未引用视图而创建。因为Backbone.js并没有执行一个关注点分离，所以你应该将其分离吗？我和许多其他的Backbone.js开发人员，如Oz Katz 和 Dayal ，都相信答案毫无疑问是yes：模型与集合，也就是数据层，应该彻底的与绑定到它们的视图无关，保持一个清晰的关注点分离。如果你没有遵循关注点分离，你的基础代码将很快变成意大利面条式的代码，而没有人喜欢意大利面条式的代码。
保持模型与视图无关将会帮助你预防意大利面条式的代码，而没有人喜欢意大利面条式的代码!