ios - NSCoding VS Core data

core-data persistence

Question

He estado buscando un artículo que explique las ventajas y desventajas de NSCoding (NSKeyedArchiver ...) sobre el uso de CoreData (SQLite ...).

Hay muchas opciones, puedo implementar mi propio lector / escritor binario personalizado, o usar plists / xml / json ... o usar SQLite o NSCoding.

Estoy un poco perdido ahora. ¿Puede alguien explicar cuál es la diferencia entre las características PRINCIPALES?

Answer 1

Depende del tipo de datos que desee guardar y si lo usará solo internamente o si tiene que intercambiar los datos con un servicio externo.

NSCoding es generalmente un serializador de datos. Una gran cantidad de objetos incorporados implementa el protocolo NSCoder que le permite guardarlos como un flujo binario (archivo, en un BLOB de un sqlite, etc.) El NSKeyedArchiver le da la ventaja de buscar en dichos flujos basándose en una etiqueta de cadena , un poco como un diccionario pero solo puedes usar cadenas como teclas. Este enfoque es bueno si ocasionalmente tiene que persistir algunos objetos de diferentes clases.

Sin embargo, si tiene muchos objetos de la misma clase, mejor opte por un enfoque de base de datos, SQLite o CoreData. CoreData es prácticamente una envoltura alrededor de SQLite que facilita mucho el diseño de su modelo de datos y realiza las consultas a la base de datos detrás de las cortinas, sin la necesidad de escribir sentencias de SQL. En CoreData usted define sus clases, y cada instancia de la clase puede persistir, es decir, puede recuperar los valores de los miembros del objeto sin tenerlos siempre en la memoria. Esta es una forma muy conveniente de almacenar una gran cantidad de datos estructurados. Por ejemplo, si escribiera un navegador web, podría almacenar los marcadores del usuario con el nombre, la URL y quizás la última vez que visitó.

Para XML y JSON, no hay ninguna ventaja en particular si utiliza los datos solo localmente en el dispositivo. Si tiene que comunicarse con algún servicio externo, puede considerar guardar en caché / guardar los objetos XML / JSON como están para su uso posterior. Otro enfoque sería regenerar estos datos a partir de sus estructuras de datos internas (ver más arriba) cada vez que lo necesite.

Si diseña usted mismo su modelo de datos, veo aún menos sentido de usar plistas, pero tal vez alguien me corrija.

EDITAR: Agrego aquí una breve referencia de enlace para tutoriales sobre cómo usar NSCoding , Core Data y, como NSCoding adicional, SQLite .

ACTUALIZACIÓN 12.01.2016: Si está buscando soluciones de persistencia, le sugiero que también eche un vistazo a Realm .

Answer 2

Mattt Thompson proporciona un desglose digerible de varias diferencias entre NSCoding , Core Data y NSKeyedArchiver en NSHipster: http://nshipster.com/nscoding/

Answer 3

Para agregar a respuestas ya excelentes, NSCoding junto con NSKeyedArchiver es una excelente manera de almacenar datos que son demasiado grandes (o tipo de datos incompatibles) para NSUserDefaults pero demasiado pequeños y no numerosos para CoreData.

Answer 4

Siempre hay una impedancia entre los objetos y las estructuras relacionales. Siempre prefiero los objetos, ya que el acceso a los datos suele ser una fracción de la funcionalidad en su aplicación. Con NSCoding, obtiene simplicidad, facilidad de depuración y control con muy poco código para escribir de todos modos. También tiene la flexibilidad de incorporar NSCoding en las estructuras de su base de datos.

NSCoding es un mecanismo de persistencia para guardar objetos. Si agrega índices a sus estructuras relacionales para la optimización de búsqueda y mantiene las estructuras de objetos, entonces creo que obtiene lo mejor de todos los mundos a un costo muy bajo y facilidad de mantenimiento.