blocks|key|191741|text|何时使用model.get(property)+model.set(...)+|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|191742|应该使用get和set来访问模型的数据。这意味着属于使用fetch检索并使用save持久化的模型序列化表示的任何属性。|191743|何时使用+model.attributes.property|191744|绝不可能。|191745|您应该始终使用get，尤其是set，而不是直接访问model.attributes对象，尽管我在这方面看到了相互矛盾的意见。我相信在model和它的消费者之间有一个契约，它保证消费者可以使用change事件通知消费者模型数据的任何变化。如果直接修改内部属性对象，则不会发送事件，并且此约定将被破坏。主干事件非常快，特别是当你没有任何监听程序的时候，这并不是从你的过度优化中获益的一点。|191746|尽管直接访问属性而不是get本身是非常无害的，但是应该避免这样做，这样attributes对象就可以被认为是完全、完全私有的。|191747|如果您绝对需要防止某些更改触发事件，则可以使用silent:true选项：model.set({key:val},+{silent:true})。这确实破坏了前面提到的契约，甚至Backbone自己的文档也给出了以下警告：|191748|191749|请注意，这很少，甚至从来都不是一个好主意。在选项中传递一个特定的标志，让你的事件回调查看并选择忽略，通常效果会更好。|blockquote|191750|191751|191752|何时使用+model.property|191753|任何不是数据的属性，即临时状态变量、计算的属性等，都可以直接附加到模型实体。这些属性应该被认为是临时的和可传递的:它们可以在模型初始化时或在其生命周期中重新创建，但它们不应该被持久化，无论是公共的还是私有的。典型的命名约定是在私有属性前面加上_字符，如下所示：|191754|this._privateProperty+=+'foo';
this.publicProperty+=+'bar';|code-block|syntax|javascript|191755|entityMap^0|4|J|O|E|4|J|O|E|0|4|3|8|3|S|5|12|4|0|0|4|5|P|5|P|0|0|7|3|E|3|P|G|1U|5|2N|6|0|B|3|Z|A|0|N|B|11|Z|0|0|0|0|0|0|4|5|E|5|E|0|3D|1|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|D]|$9|1G|A|1H|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|1I|8|@$9|1J|A|1K|B|D]|$9|1L|A|1M|B|D]|$9|1N|A|1O|B|D]|$9|1P|A|1Q|B|D]]|E|@]|F|$]]|$1|I|3|J|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]|$9|1W|A|1X|B|D]]|E|@]|F|$]]|$1|K|3|L|5|6|7|1Y|8|@]|E|@]|F|$]]|$1|M|3|N|5|6|7|1Z|8|@$9|20|A|21|B|D]|$9|22|A|23|B|D]|$9|24|A|25|B|D]|$9|26|A|27|B|D]|$9|28|A|29|B|D]]|E|@]|F|$]]|$1|O|3|P|5|6|7|2A|8|@$9|2B|A|2C|B|D]|$9|2D|A|2E|B|D]]|E|@]|F|$]]|$1|Q|3|R|5|6|7|2F|8|@$9|2G|A|2H|B|D]|$9|2I|A|2J|B|D]]|E|@]|F|$]]|$1|S|3|-4|5|6|7|2K|8|@]|E|@]|F|$]]|$1|T|3|U|5|V|7|2L|8|@]|E|@]|F|$]]|$1|W|3|-4|5|6|7|2M|8|@]|E|@]|F|$]]|$1|X|3|-4|5|6|7|2N|8|@]|E|@]|F|$]]|$1|Y|3|Z|5|6|7|2O|8|@$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|C]|$9|2T|A|2U|B|D]]|E|@]|F|$]]|$1|10|3|11|5|6|7|2V|8|@$9|2W|A|2X|B|D]]|E|@]|F|$]]|$1|12|3|13|5|14|7|2Y|8|@]|E|@]|F|$15|16]]|$1|17|3|-4|5|6|7|2Z|8|@]|E|@]|F|$]]]|18|$]]

When to use <code>model.get(property)</code> and <code>model.set(...)</code>

You should use <code>get</code> and <code>set</code> to access the model's data. This means any attributes that are part of the model's serialized representation that is retrieved using <code>fetch</code> and persisted using <code>save</code>.

When to use <code>model.attributes.property</code>

Never.

You should always use <code>get</code>, and especially <code>set</code>, instead of accessing the <code>model.attributes</code> object directly, although I've seen conflicting opinions about this. I believe there is a contract between a <code>model</code> and it's consumers, which guarantees that the consumer can be notified of any changes to the model's data using the <code>change</code> event. If you modify the internal attributes object directly, events are not sent and this contract is broken. Backbone events are very fast, especially if you don't have any listeners attached to them, and it's not a point that benefits from over-optimization on your part.

Although accessing the attributes directly instead of <code>get</code> is quite harmless on it's own, it should be avoided so the <code>attributes</code> object can be considered totally, completely private. 

If you absolutely need to prevent some change triggering events, you can use the <code>silent:true</code> option: <code>model.set({key:val}, {silent:true})</code>. This does break the aforementioned contract, and even Backbone's own documentation gives the following caveat:

<blockquote>
 Note that this is rarely, perhaps even never, a good idea. Passing through a specific flag in the options for your event callback to look at, and choose to ignore, will usually work out better.
</blockquote>

When to use <code>model.property</code>

Any properties which are not data, i.e. temporary state variables, calculated properties etc. can be attached directly to the model entity. These properties should be considered temporary and transitive: they can be recreated upon model initialization or during its lifetime, but they should not be persisted, whether public or private. A typical naming convention is to prefix private properties with the <code>_</code> character as follows:

<pre><code>this._privateProperty = 'foo';
this.publicProperty = 'bar';
</code></pre>

blocks|key|196025|text|Never是一个不完整的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|196026|有时，您希望访问模型属性的集合-无论这些属性是什么。考虑一种实用方法，用于对属性执行计算、格式化属性以进行输出等。|196027|要做到这一点，一个方便的方法是访问model.attributes|196028|考虑一种替代方案，如下：|196029|var+attributesNames+=+['foo',+'bar',+'baz'];
var+attributes+=+_(attributesNames+).map(function(attr)+{+return+model.get(attr);+});

callSomeUtilityMethod(attributes);|code-block|syntax|javascript|196030|两个问题：|196031|196032|我们已经在"attributeNames“集合中引入了耦合。如果列表改变了怎么办？|unordered-list-item|196033|我们已经失去了名称/值的关联。我们可以重写上面的地图，但它会变得更多工作。|196034|196035|在这种情况下，这样做要方便得多：|196036|callSomeUtilityMethod(model.attributes);|196037|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|15|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|R|7|19|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1B|8|@]|9|@]|A|$]]|$1|X|3|Y|5|J|7|1C|8|@]|9|@]|A|$K|L]]|$1|Z|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|10|$]]

Never is an incomplete answer. 

Sometimes you want access to the collection of model attributes - whatever those attributes might be. Consider a utility method to perform calcs on attributes, format them for output, etc.

A convenient way to do this is to access model.attributes

Consider one alternative, below:

<pre><code>var attributesNames = ['foo', 'bar', 'baz'];
var attributes = _(attributesNames ).map(function(attr) { return model.get(attr); });

callSomeUtilityMethod(attributes);
</code></pre>

Two problems:

<ul>
<li>We've introduced coupling in the "attributeNames" collection. What if that list changes?</li>
<li>We've lost the association of name/value. We could rewrite the map above, but it becomes more work.</li>
</ul>

In this scenario, it's much more convenient to do something like this:

<pre><code>callSomeUtilityMethod(model.attributes);
</code></pre>

From my understanding the attributes of a Backbone.js model are supposed to be declared as somewhat private member variables by saying

<pre><code>this.set({ attributeName: attributeValue })
// accessing the value
this.get('attributeName');
</code></pre>

But when I am writing functions whitin the actual model it seems much simpler to say like this:

<pre><code>this.attributeName = attributeValue;
// accessing the value
this.attributeName;
</code></pre>

Also I would assume that the latter version would be faster to process since it doesn't go through backbone.js's event management.

So I was wondering how you pros do with attributes that are primarily used internally in the model. These are the attributes that one would actually want to be a bit shielded from the outside so having them exposed like in the latter example maybe isn't right still. When I have been looking at examples for the backbone.js view which doesn't have get and set methods it seems fine to do like in the second example. So is there any nice rule of thumb when to use get/set(attribute) or this.attribute when coding within the model? Or maybe an example of a model that makes this clearer?

backbone.js accessing model attributes within model - this.attribute VS this.get('attribute')?

据我所知，Backbone.js模型的属性应该声明为一些私有成员变量，方法是this.set({ attributeName: attributeValue })// accessing the valuethis.get('attributeName');但是，当我在实际模型中编写函数时，看起来像这样说要简单得多：t...

问backbone.js访问模型中的模型属性- this.attribute与this.get('attribute')？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问backbone.js访问模型中的模型属性- this.attribute与this.get('attribute')？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问backbone.js访问模型中的模型属性- this.attribute与this.get('attribute')？
EN