的地方在于，如果在你处理不同的属性error时并没有太多的不同的话，你的视图可能会变得极为膨胀。

　　这两种模式都有其利弊，你应该考虑清楚哪个模式对你的应用案例是最优的。如果你按照同样的方式处理所有失败的验证，那么第一个方法可能是最好的;如果你对每个模型属性有特定的UI变化，那么后一种方法更好。

　　HTTP状态代码200所触发的错误

　　如果你的浏览器端模型或者集合收到了无效的JSON，尽管HTTP的状态代码是200，但浏览器端依然会触发一个“错误”事件。这种事件常发生于本地模拟JSON数据造成的。那么，一个好的方法就是读取经过 JSON 验证器验证了的模拟JSON数据文件。或者从你的IDE获得相应的 插件来及时获取格式错误的JSON信息。

　　创建一个一般性错误显示模式

　　创建一个常见错误显示代码可以节省你的时间以及创建一个统一的模式来处理、可视化错误信息，而且它可以增加开发者的经验。我之前开发的每一个Backbone.js应用中我都会创建一个可以处理alert的视图：

　　?

也要知道一个小小的性能影响都来自于执行一个深度的克隆，但是我从来没有看到过很明显的问题。然而，如果你要深度的克隆一个大对象或者成千上万的对象所有的立即复制，你将有可能做大量的性能分析。这将领导我们直接到下一个模式。

　　为对象创建外观

　　在现实世界中，需求经常变化，JavaScript对象符号(或者说JSON)也是一样，这些对象是由模型和集合所在的端点返回的。这或许会成为你的基础代码中的一个真正的大麻烦，如果你的视图与底层的数据模型是紧耦合的话。因此，我为所有对象创建了getters和setters。

　　支持这个模式的人非常多。如果任何底层的数据结构改变了，那么视图层并不需要更新许多;你将有一个数据的访问点，所以你不太可能忘记做一个深度拷贝，你的代码将会更易于维护更易于调试。负面因素在于这个模式可能导致模型或集合的一点点膨胀。

　　我们看一个例子来阐明这个模式。想像我们有一个Hotel模型，包含有rooms和目前可获得的rooms，而且我们希望可以通过床位大小来获得rooms。

　　?

　　我们仅仅更新了一个函数，以便将Hotel的结构转变为这个应用的其余部分所期望的结构，同时整个应用仍然像我们所期待的一样运作。如果这里没有一个getter，我们很可能不得不为rooms更新每个访问点。理想情况下，你会希望更新所有的函数，以适应新的数据结构，但如果你在时间方面有压力急于发布的话，这个模式将可以拯救你。

　　离题说一句，这个模式既可以被认为是装饰模式，因为它隐藏了创建对象拷贝的复杂性，也可以认为是桥接模式，因为它可以用来将数据转换为所期望的形式。一个好的经验是对任何对象元素使用getters 和setters 。

　　存储数据不是通过服务器保存

　　尽管Backbone.js有模型和集合映射的规定去具象状态的传输(or REST-ful)的端点，你将花大量的时间去找你想要的存储数据在你的模型或者不是在服务器上的连接。另外一些关于Backbone.js的文章，例如“Backbone.js Tips: Lessons From the Trenches” 是通过SupportBee的Prateek Dayal ，这个模式还有其他的描述。让我们一起来快速的看一个小例子来帮助我们说明它可能会派上用场。假设你有一个集合。

　　?

更多精彩内容 扫码关注我们

Backbone.js的一些使用技巧

教程 >

　　这篇文章主要介绍了Backbone.js的一些使用技巧,Backbone.js是一款人气JavaScript库,需要的朋友可以参考下　　自从3年前Backbone.js发...

　　现在我们能够很容易的判断被选中的项目，并且我们没有必要通过对象模型去判断。这种模式对于存储无用的数据是非常有用的以至于 你可能非常想要去跟踪;请记住你能够创建一个模型并且没有必要去关联于他们存储的一些无用的图像数据。

　　?

　　现在我们可以很容易的确定哪些项已经被选中，并且我们没有必要通过这些对象模型来了解。这个模式对于存储无用的数据是非常有用的，请记住,您可以创建不一定有端点相关联的存储无关的视图数据的模型和集合。

　　这种模式的缺点是你存储了无用的数据在你的模型或者集合中，它们不能真正意义上的追随一个平静的架构是因为它们不会完美的去映射在web资源上;另外，这个模式会引起一些很膨胀的在你的模型中;;并且当你保存你的模型的时候如果你的端点严格的只接受JSON数据它会引起一个很大的烦恼。

　　你可能会问你自己，“我如何确定我是否应该讲把额外的数据放进视图或者是模型中?”。如果额外的属性你将要增加的是围绕性的呈现，例如一个容器的高度，我们应该要添加它的图形。如果这个属性跟底层的数据模型有一些关系，然后你想要将它放进这个模型中。例如，如果上面的例子更多的显露出，因为某些原因我仅仅只希望用户通过从模型返回的项目列表中选择一个特殊的项,我可能会增加这种逻辑模型。总而言之，大多数的事情，它实际上取决于这种依赖。你能够为保持你的模型而辩论并且你可以认为保持你的观点是可能的并且把尽可能多的逻辑放进你的模型中。

　　渲染部分视图,而不是整个视图

　　当你第一次开始开发Backbone.js应用时，典型的视图结构是像这样的：

　　?

..12 下一页

【更多相关】：

相关推荐：

　　在这里，任何对模型的改变都会触发对视图的一个全面的重新渲染。我第一次用Backbone.js开发时，我是这个模式的实践者。但随着视图代码的增长，我迅速的意识到，这种方法不利于维护或优化，因为当模型的任何一个属性发生变化时，视图将会完全的重新渲染。

　　当我遇到这个问题，我迅速的用Google搜索了一下，看看别人是怎么做的，结果找到了Ian Storm Taylor的博客，“分解你的Backbone.js渲染方法”，他在其中描述了在模型中监听单独的属性变化，然后仅仅重新渲染相对于变化属性的视图部分。Taylor也描述了返回对象的引用，以便单独的渲染函数可以很容易的链接在一起。上面的例子现在现在就变得更易于维护，性能更优。因为我们仅仅更新了模型变化的属性相对应的视图部分。

　　?

迅速的深入到基础代码之中，因为他们会确切的知道哪里发生了渲染，哪里存在有你的应用的所有商务逻辑。

　　这个模式也执行了单一职责原则，规定了每个类应该具有一个单一的职责，而且它的职责应该封装与这个类之中，因为模型与集合要处理数据，而视图要处理渲染。

　　路由中的参数

　　最好的演示这个模式工作方式是举个例子。比如说你需要对搜索页面进行排序，每个搜索页面都允许用户添加两个不同的过滤类型foo和bar，每个类型代表不同的观点。

　　因此，你的URL结构将会呈现如下：

　　?

更多精彩内容 扫码关注我们

Backbone.js的一些使用技巧

教程 >

　　这篇文章主要介绍了Backbone.js的一些使用技巧,Backbone.js是一款人气JavaScript库,需要的朋友可以参考下　　自从3年前Backbone.js发...

面的例子将这个概念形象化了。

　　?

　　PUTs 需要一个 ID 属性