backbone.js accéder aux attributs de modèle dans le modèle.attribut VS ce.get ("attribut")?

À partir de ma compréhension des attributs d'un Backbone.js modèle sont censés être déclaré comme un peu des variables de membre privé en disant

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

Mais quand je suis à l'écriture de fonctions dans le modèle actuel, il semble beaucoup plus simple à dire comme ceci:

this.attributeName = attributeValue;
//accessing the value
this.attributeName;

Aussi je suppose que la dernière version est plus rapide de processus, car il ne fonctionne pas backbone.js'la gestion de l'événement.

Donc je me demandais comment vous les pros le faire avec des attributs qui sont principalement utilisés en interne dans le modèle. Ce sont les attributs que l'on a réellement envie d'être un peu à l'abri de l'extérieur, de sorte de les avoir exposés comme dans le dernier exemple n'est peut-être pas encore. Quand j'ai été en regardant des exemples pour l'backbone.js point de vue qui n'ont pas les méthodes get et set, il semble correct de faire comme dans le deuxième exemple. Donc, il y a un joli règle de base lors de l'utilisation de get/set(attribut) ou du présent.attribut lors du codage dans le modèle? Ou peut-être un exemple de modèle qui rend ce plus clair?

pourquoi voudriez-vous éviter l'épine dorsale de la gestion de l'événement ? il pourrait y avoir des points de vue y écouter un certain attribut, peu importe si elles sont mises à jour à l'intérieur ou à l'extérieur de la colonne vertébrale.Modèle ?
Je pensais juste que quand j'ai par exemple ma demande de mise à jour de certains attributs de modèle toutes les 16 millisecondes, ce ne serait pas une bonne idée à feu de tous ces événements à chaque fois? La plupart des exemples que j'ai rencontré sont sur Todo-listes et d'autres choses qui ne veut pas se mettre à jour fréquemment.
Pour le privé, le modèle de données que je viens de faire this._propName, plutôt que de le mettre dans la gestion de la zone de la colonne vertébrale, Model objet.

OriginalL'auteur torno | 2013-03-21

  1. 54

    Quand utiliser model.get(property) et model.set(...)

    Vous devez utiliser get et set pour accéder au modèle de données. Ceci signifie que tous les attributs qui font partie du modèle de représentation sérialisée qui est récupéré à l'aide fetch et a persisté à l'aide de save.

    Quand utiliser model.attributes.property

    Jamais.

    Vous devriez toujours utiliser get, et surtout set, au lieu d'accéder à la model.attributes objet directement, bien que j'ai vu des avis divergents à ce sujet. Je crois qu'il existe un contrat entre un model et ce sont les consommateurs, qui garantit que le consommateur puisse être informé de toute modification du modèle de données à l'aide de la change événement. Si vous modifiez l'intérieur des attributs de l'objet directement, les événements ne sont pas envoyés, et le présent contrat est rompu. Épine dorsale événements sont très rapide, surtout si vous n'avez pas tout les auditeurs attaché à eux, et ce n'est pas un point qui bénéficie de la sur-optimisation de votre part.

    Bien que l'accès des attributs directement au lieu de get est tout à fait inoffensif sur son propre, il devrait être évité si le attributes objet peut être considéré comme totalement, complètement privé.

    Si vous devez absolument éviter que certains changement de déclenchement d'événements, vous pouvez utiliser le silent:true option: model.set({key:val}, {silent:true}). Cela ne pause le dit contrat, et même l'épine Dorsale de la documentation propre donne l'avertissement suivant:

    Noter que ce qui est rarement, voire jamais, une bonne idée. En passant par un indicateur spécifique dans les options de votre événement de rappel à regarder, et choisir de l'ignorer, généralement mieux.

    Quand utiliser model.property

    Toutes les propriétés qui sont pas de données, c'est à dire temporaire variables d'état, des propriétés calculées etc. peut être fixé directement sur le modèle de l'entité. Ces propriétés doivent être considérés comme temporaires et transitif: ils peuvent être recréés sur le modèle de l'initialisation ou pendant sa durée de vie, mais ils ne devraient pas être conservées, qu'elles soient publiques ou privées. Typique de la convention de nommage est le préfixe de propriétés privées avec le _ caractère comme suit:

    this._privateProperty = 'foo';
this.publicProperty = 'bar';
    La réponse ne peut Jamais être proposé à un débutant. Mais si vous travaillez déjà sur un plus projet complexe qui travaille avec de grands ensembles de données, vous DEVEZ absolument travailler avec le modèle.attributs, car elle est beaucoup plus rapide que d'utiliser des méthodes set/get avec leurs frais généraux.
    pouvez-vous prouver qu'avec certains tests de perf?

    OriginalL'auteur jevakallio

  2. 2

    N'est jamais une réponse incomplète.

    Parfois, vous voulez accéder à la collection des attributs de modèle - ce que ces attributs peuvent être. Envisager une méthode utilitaire pour effectuer des calcs sur les attributs, le format de sortie, etc.

    Un moyen pratique de faire cela est de modèle d'accès.attributs

    Envisager une alternative, ci-dessous:

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

callSomeUtilityMethod(attributes);

    Deux problèmes:

    • Nous avons introduit de couplage dans la "attributeNames" de la collection. Que faire si que les modifications de la liste?
    • Nous avons perdu l'association du nom/valeur. Nous pourrions réécrire la carte ci-dessus, mais il devient de plus en plus de travail.

    Dans ce scénario, il est beaucoup plus pratique de faire quelque chose comme ceci:

    callSomeUtilityMethod(model.attributes);
    Je ne recommanderais pas cela. Non seulement vous exposer l'intérieur de leurs attributs, mais vous êtes en l'exposant à une autre méthode qui peut ne pas être au courant qu'il représente l'état interne d'un modèle. Si callSomeUtilityMethod méthode modifie l'objet, il le reçoit comme un argument, c' (accidentellement) modifie également l'état du modèle. Dans ce cas, je voudrais utiliser callSomeUtilityMethod(model.toJSON());, qui a effectivement clones du modèle attributs et évite toute difficile à déboguer les problèmes.
    d'amende lorsque votre modèle ne contient que des primitives. Pas si fine, si votre modèle contient des objets que vous voudrez peut-être mutable quelle que soit la fonction que vous utilisez.
    BTW: je considère cela comme une caractéristique qui n'est pas un bug. Caveat emptor (d'où le "plus Jamais est incomplète"). Potentiellement un problème plus grave, c'est quand vous avez remplacé votre modèle get() pour faire de intelligent "magic" qui je fais tout le temps.
    pas bien, même si votre modèle contient les primitives. Envisager function callSomeUtilityMethod(options) { options.foo='bar'; }, qui est toujours en évolution du modèle de l'état.
    Veuillez voir mon commentaire: je considère cela comme une caractéristique qui n'est pas un bug. Vous pouvez facilement imaginer les grandes catégories de problèmes qui ont besoin de ce paradigme.

    OriginalL'auteur Aaron Averill