2011-02-11 23 views
23

Me pregunto si debería guardar los datos de mi aplicación en un plist o utilizar Core Data ..¿Debo guardar en plist o Core Data?

Mi aplicación simplemente está guardando tweets de la línea de tiempo y otros usuarios ahora. Que es menos de unos pocos kilobytes kB (aproximadamente 200 kb en mi prueba). ¿Cuáles son las ventajas de usar datos centrales?

Respuesta

22

No consideraría las listas para nada más que para guardar las preferencias simples y la estructura de datos realmente básica. Además, en cuanto a rendimiento, recuperar y guardar datos en listas puede ser bastante lento.

Después de luchar con CoreData durante mucho tiempo, ahora que por fin lo entiendo yo elegiría por encima de cualquier cosa en cualquier momento. Sí, tiene un poco de una curva de aprendizaje abrupta, pero hay tanto que obtienes "gratis" con él, definitivamente invertiría el tiempo para aprender y explorarlo.

Coredata le dará la flexibilidad de expandir sus modelos de objetos según sea necesario, buscar objetos fácilmente desde el almacenamiento persistente basado en ciertos parámetros, crear relaciones entre modelos, administrar la memoria y la lista continúa.

Coredata está muy bien documentada por Apple, por lo que encontrará todo lo que necesita para comenzar y más. Hay ejemplos, ejemplos de proyectos, videos, lo que sea, así que definitivamente recomendaría que eche un vistazo SI le interesa el rendimiento, la escalabilidad y también un poco de diversión :)

+0

¿Pero realmente vale la pena por unos pocos KB de datos almacenados? También estoy planeando hacer Core Data en algún momento, pero solo tengo unas semanas más hasta la prueba beta ... ¿Así que crees que debería seguir con el plist? –

+3

Bueno, no es como si no pudieras decidir mudarte a Coredata en el futuro si fuera necesario. Si necesita velocidad para comercializar en este momento, vaya con los plists, ya que será un pedazo de pastel para implementar. – Rog

13

Como ya se mencionó, escribiendo a un plist y leer de un plist es casi trivial usando NSDictionary. Entonces esa podría ser una buena forma de comenzar.

Dicho esto, si el modelo de datos se inicia cada vez más ricos y las relaciones con los atributos adicionales, después de Datos Básicos proporcionaría una mejor escala y un mejor soporte. Xcode hace que sea muy fácil diseñar su modelo de objeto (esquema) e incluso generará archivos fuente, en caso de que decida subclase NSManagedObject (que casi siempre hago).

Conclusión: Plist lo pondrá en funcionamiento más rápido; Core Data le dará mucho poder cuando llegue el momento.

+2

Ustedes me están haciendo desear tener más tiempo ... Realmente quiero aprender Core Data ahora, pero tal vez no lo use en esta aplicación ya que tengo que enviarlo en unas pocas semanas. –

+1

Llegué a la misma conclusión. Una de mis aplicaciones tenía un pequeño conjunto de datos básicos, por lo que opté por usar listas en lugar de datos básicos. En general, creo que lo mejor es aprovechar únicamente las API/características más complicadas y potentes si realmente las necesitan. – LucasTizma

38

solo algunos consejos que podrían ayudar en el diseño de su aplicación.

Antes que nada sería bueno subrayar que CoreData no es realmente comparable con plist. Lo que quiero decir es que CoreData es como una capa de abstracción del modelo de datos sobre su almacenamiento de datos que le permite administrar las relaciones y obtener reglas entre las diferentes entidades de datos. Detrás de la capa CoreData, su almacenamiento de datos podría basarse en plist (solo osx), base de datos sqlite u objeto binario.

Esto también es importante porque lo ayuda a entender el alcance de CoreData: si necesita mantener una relación lógica entre diferentes entidades de datos o realizar múltiples consultas sobre los mismos datos o serializar/deserializar estructuras de big data, CoreData proporciona la mejor La solución más rápida para hacerlo realidad. Si solo necesita almacenar una lista simple de elementos que solo necesitan mostrarse, un rebote de un archivo plist debería ser suficiente.

Otro punto importante es la decisión del tipo de datos que necesita para almacenar: según Apple, archivos plist están optimizados para cadenas, números, fechas y algunos datos binarios. Esto es lo que dice que Apple sobre plist:

Note that property lists should be used for data that consists primarily 
of strings and numbers. They are very inefficient when used with large blocks 
of binary data.
Many applications require a mechanism for storing information that will 
be needed at a later time. For situations where you need to store small 
amounts of persistent data — say less than a few hundred kilobytes — property 
lists offer a uniform and convenient means of organizing, storing, and 
accessing the data.

Esto significa que si usted necesita para almacenar cosas "pesada" o objetos complejos y gestionarlos (como la búsqueda de ellos valle), el sistema de almacenamiento en caché del analizador plist podría ser ineficiente (principalmente en iOS).

En mi opinión, su idea de almacenar alrededor de 200k de tweets lineales (alrededor de 1000 tweets?) De una línea de tiempo funcionará bien con una solución basada en plist. También considere que el analizador plist se acelera fuertemente con una estructura de datos pequeña, entonces tendrá un mejor rendimiento y menos uso de memoria (principalmente durante el inicio) porque no necesita inicializar CoreData ni ningún otro "envoltorio de código" alrededor de su almacenamiento de datos. Solo un simple uso sobre la marcha de NSDictionary, NSArray y más.

Por último, la implementación plist es lo suficientemente económica como para darle la posibilidad de avanzar en CoreData en un siguiente paso.

Lo que quiero decir es que a veces no es necesario el uso de un tanque si es necesario coger algunas moscas :-)

Espero que esto ayude. Ciao!