java - especifico - Matriz de objetos vs Objeto de objetos
eliminar un elemento especifico de un array javascript (5)
El problema es decidir las compensaciones entre las siguientes anotaciones:
Basado en JSON :
"users": {
"id1": {
"id": "id1",
"firstname": "firstname1",
"lastname": "lastname1"
},
"id2": {
"id": "id2",
"firstaame": "firstname2",
"lastname": "lastname2"
}
}
Basado en matriz :
users: [
{
"id": "id",
"key2": "value2",
"key3": "value3"
},
{
"id": "id",
"key2": "value2",
"key3": "value3"
}
]
En relación con this publicación sobre el mismo tema, he decidido (en el front end) usar la notación de objetos JSON en lugar de una matriz de objetos, ya que se ajusta a mis requisitos y me permite un mejor rendimiento y menos código en el navegador.
Pero el problema es que la lista en sí no es estática. Con esto quiero decir que la lista se genera, es decir, se busca / almacena desde DB (NoSQL) y se crea para nuevas entradas a través de una API de Java en el servidor. No puedo decidir qué notación debo usar en la parte posterior (lo que eventualmente también afectará a la UI).
Se aprecia cualquier pensamiento / sugerencia sobre el rendimiento, la facilidad de mantenimiento o la escalabilidad.
Ambos enfoques tienen sus pros y sus contras y dependen de qué es lo que estás mirando.
El enfoque de matriz es fácil de serializar y es más amigable con el "marco" (puede agregar beans a una lista y serializar la lista y listo). Esto permite, por ejemplo, un contenedor web para devolver la respuesta sin requerir ninguna personalización. Es probable que sea compatible con la mayoría de los frameworks desde el primer momento.
Por otro lado, el enfoque basado en objetos es más difícil de generar (en términos relativos) pero es más fácil de buscar dada la clave que se conoce.
Por lo tanto, para facilitar la implementación (por productor), elija el enfoque basado en arreglos. Para facilitar el uso (consumido por los clientes) opte por un enfoque basado en objetos.
En el lado del servidor, las matrices se almacenan como listas simples: ArrayList<Content> , mientras que los objetos se almacenan como mapas: HashMap<String, Content> o, sobre todo, como objetos de Java.
Para convertir entidades Java a JSON, puede echar un vistazo al proyecto Jackson , que hace todo eso por usted.
No me preocuparía ninguna diferencia de rendimiento entre esas dos variantes. Es más importante tener una API semántica comprensible, por lo que debe basar su decisión en el caso de negocio en lugar del rendimiento.
En cuanto a su ejemplo, creo que una Array es el mejor enfoque, ya que desea devolver una lista de usuarios que son todos iguales. Enviar el ID dos veces no tiene sentido y aumenta la cantidad de datos que se deben transmitir.
Además, dado que las Arrays son mucho más simples de almacenar e iterar en Java, también deberían proporcionar un mejor rendimiento que los objetos.
Algunas diferencias generales:
- Las matrices conservan la orden
- Las matrices pueden contener entradas duplicadas
- Los objetos a menudo tienen una mayor sobrecarga de almacenamiento / red
- Las matrices son más rápidas de iterar (en el lado del servidor)
Es una pregunta basada en la opinión total. Puede haber muchos otros puntos, pero puedo señalar lo siguiente.
Enfoque basado en JSON: si no estoy equivocado, esto se implementará utilizando Map en el lado del servidor.
Ventaja: en JavaScript puede usar users.id1, users.id2 directamente, es decir, no necesita iteración
Desventaja: en el lado del cliente, de alguna forma necesitará los identificadores presentes en su JSON, es decir, ya sea codificándolo o utilizando un enfoque dinámico que le dirá qué identificación está presente en su JSON.
Enfoque basado en Array: si no estoy equivocado, esto se implementará usando Array / List en el lado del servidor.
Ventaja:
- En el lado del cliente, puede iterar directamente a través de la matriz, sin preocuparse de antemano acerca de qué ID está presente en su interior, es decir, no hay una codificación difícil.
- Como señaló @JBNizet , el enfoque basado en arreglos mantendrá el orden.
Desventaja: si desea obtener una identificación única, deberá iterar a través de la matriz.
En general, no enviamos mucha información por el lado del cliente, por lo que el enfoque basado en arreglos no creará ningún problema. Y la transformación de la matriz en mapa es posible tanto en el lado (servidor y cliente) si desea un enfoque basado en la identificación.
Puede usar la notation object[property] para acceder o establecer propiedades en un objeto en JavaScript.
Vaya con el enfoque basado en arreglos en el servidor, y conviértalo en un mapa ( basado en JSON como se lo refiere) en el front-end.
var list = [{id: "id1", value: "One"}, {id: "id2", value: "Two"}]
var map = {};
list.forEach(function (item) { map[item.id] = item });
map.get("id1")
Si su lista cambia, puede obtener la nueva lista del backend y actualizar su mapa en la interfaz de usuario.
De esta forma, su back-end es más rápido de responder ya que no tiene que convertir la lista en un mapa. Su parte delantera realizará una iteración O (n) una vez sobre la lista para convertirla en un mapa. Pero ese es un precio pequeño en comparación con O (n) que pagará cada vez que busque en una lista.
Si va a hacer get by id predominantemente en sus datos en el back-end, vaya con JSON Based en el back-end mismo (puede usar LinkedHashMap para conservar el orden).
Una gran desventaja de su primera notación "basada en JSON" que viene a la mente es que algunos marcos tendrán problemas con la (des) serialización de esto. Por ejemplo, DataContractSerializer (C # .NET) esperará que los campos id1 e id2 se definan (codificados) en la clase de users de sus objetos. No estoy seguro de si esto se aplica a algunos frameworks Java, también. Tal vez el marco que utilizará puede deserializarlo como un HashMap.
En general, creo que la notación de matriz es mucho más intuitiva para trabajar cuando se trata de iteración, etc.