backbone.js el acceso a atributos de modelo en modelo – este.atributo VS.get(‘atributo’)?

De mi comprensión de los atributos de un Backbone.js el modelo se supone que para ser declarado como algo variables miembro privadas diciendo

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

Pero cuando estoy escribiendo funciones whitin el modelo real, parece mucho más simple decir como esta:

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

También quiero suponer que la última versión sería más rápido el proceso ya que no se puede ir a través de backbone.js’s la gestión de eventos.

Así que me preguntaba cómo pros ver con los atributos que se utilizan principalmente internamente en el modelo. Estos son los atributos que uno realmente quiere ser un poco blindado desde el exterior, así que tenerlos expuestos como en el último ejemplo tal vez no está bien todavía. Cuando he estado buscando ejemplos para la backbone.js punto de vista que no tiene métodos get y set que parece bien a hacer como en el segundo ejemplo. Así que es allí cualquier agradable regla de oro cuando el uso de get/set(atributo) o este.atributo cuando la codificación dentro del modelo? O tal vez un ejemplo de un modelo que hace esto más claro?

¿por qué quieres evitar que la columna vertebral de la gestión de eventos ? no podría ser vistas escuchando a cierto atributo con independencia de si están actualizados dentro o fuera de la columna vertebral.Modelo ?
Sólo pensé que cuando yo por ejemplo en mi actualización de la aplicación de algún modelo de los atributos de cada 16 milisegundos no sería una buena idea para disparar a todos los eventos de cada vez? La mayoría de los ejemplos que he encontrado son sobre Todo-listas y otras cosas que no se actualizan con frecuencia.
Por privado datos del modelo acabo de hacer this._propName, en lugar de ponerlo en el administrado de la zona de la columna vertebral Model objeto.

OriginalEl autor torno | 2013-03-21

2 respuestas

  1. 55

    Cuando el uso de model.get(property) y model.set(...)

    Debe utilizar get y set para acceder a la modelo del datos. Esto significa que todos los atributos que forman parte del modelo de la representación serializada que se recupera mediante fetch y conserva mediante save.

    Cuando el uso de model.attributes.property

    Nunca.

    Usted siempre debe usar get, y especialmente set, en lugar de acceder a la model.attributes objeto directamente, aunque he visto opiniones contradictorias acerca de esto. Creo que hay un contrato entre un model y los consumidores, lo que garantiza que el consumidor puede ser notificada de cualquier cambio en los datos del modelo, utilizando la change evento. Si modifica la interna de los atributos del objeto directamente, los eventos no son enviados, y este contrato se rompe. Columna vertebral eventos son muy rápido, especialmente si usted no tiene ningún tipo de oyentes conectados a ellos, y no es un punto que se beneficia de la sobre-optimización de su parte.

    Aunque el acceso a los atributos directamente en lugar de get es bastante inofensivo en sí mismo, que debe ser evitado para el attributes objeto puede ser considerado totalmente, totalmente privado.

    Si es absolutamente necesario evitar algunos cambios eventos de activación, puede utilizar el silent:true opción: model.set({key:val}, {silent:true}). Esto no romper dicho contrato, e incluso la columna vertebral de la propia documentación da la siguiente advertencia:

    Nota que es rara vez, tal vez incluso nunca, una buena idea. Pasando a través de un determinado indicador en las opciones para su evento de devolución de llamada para mirar, y elegir ignorar, por lo general, trabajar mejor.

    Cuando el uso de model.property

    Las propiedades que se no datos, es decir, temporales de las variables de estado, las propiedades calculadas etc. puede ser conectado directamente a la entidad de modelo. Estas propiedades deben ser considerados temporal y transitiva: pueden ser recreados al modelo de inicialización o durante su vida útil, pero no debe ser persistente, ya sea pública o privada. Un típico convención de nomenclatura es prefijo de propiedades privadas con el _ carácter de la siguiente manera:

    this._privateProperty = 'foo';
    this.publicProperty = 'bar';
    La respuesta Nunca puede ser sugerido para un principiante. Pero si alguna vez trabajo en un proyecto complejo que trabaja con conjuntos de datos más grandes, es absolutamente necesario trabajar con el modelo.atributos, porque es mucho más rápido que usando set/get métodos con sus gastos de estructura.
    se puede demostrar que con algunos perf pruebas?

    OriginalEl autor jevakallio

  2. 2

    Nunca es una respuesta incompleta.

    A veces se desea que el acceso a la colección de atributos de modelo – de lo que los atributos se puede. Considere la posibilidad de un método de utilidad para realizar calcs en los atributos, el formato de salida, etc.

    Una manera conveniente de hacer esto es el modelo de acceso.atributos

    Considerar una alternativa a continuación:

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

    Dos problemas:

    • Hemos introducido acoplamiento en el “attributeNames” de la colección. Lo que si que los cambios de la lista?
    • Hemos perdido la asociación de nombre/valor. Podríamos reescribir el mapa de arriba, pero se vuelve más trabajo.

    En este escenario, es mucho más conveniente para hacer algo como esto:

    callSomeUtilityMethod(model.attributes);
    Yo no recomendaría hacer esto. No sólo se están exponiendo a la interna de los atributos, pero se están exponiendo a otro método que puede no ser consciente de que representa el estado interno de un modelo. Si callSomeUtilityMethod método modifica el objeto que recibe como argumento, (accidentalmente) también modifica el estado de la modelo. En este caso yo lo uso callSomeUtilityMethod(model.toJSON());, que efectivamente los clones el modelo de los atributos y evita cualquier difíciles de depurar problemas.
    bien cuando su modelo sólo contiene primitivas. No tan fina cuando el modelo contiene los objetos que desea ser mutable en cualquier función que está utilizando.
    BTW: considero que esto es una característica que no es un error. Caveat emptor (de ahí el “Nunca es incompleta”). Posiblemente el problema más serio es cuando se ha reemplazado el modelo get() para hacer algunas inteligente “magia” que hago todo el tiempo.
    no bien incluso cuando el modelo contiene primitivas. Considere la posibilidad de function callSomeUtilityMethod(options) { options.foo='bar'; }, que todavía los cambios del modelo de estado.
    Por favor, ver mi comentario: considero que esto es una característica que no es un error. Usted puede fácilmente imaginar grandes categorías de problemas que requieren de este paradigma.

    OriginalEl autor Aaron Averill

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *