Reputation: 29314
Typically I use Core Data in my applications, but for my current project I don't need data to persist launch to launch.
Because of that, I'm wondering how I should store my data. It's not going to be tens of thousands of items or anything, hundreds at the high end most likely.
I'm still going to create an NSObject
subclass to represent each "entry" in the database, but what should I store that in? A simple NSMutableArray
that's a property? Should I have a distinct model class? Should I still be using Core Data somehow?
What's the accepted/best practice for a situation like this?
Upvotes: 1
Views: 318
Reputation: 41226
Since you're not worried about persistence, it seems simplest to just use a wrapper around an NSMutableArray (or NSMutableDictionary if indexing is more important that ordering) Since you can apply NSPredicates to arrays you've still got the ability to do very dynamic database style sorting and searching without some of the drawbacks of core data.
Use a wrapper instead of just using an array because that gives you a convenient place to put sorting and searching options, as well as possibly giving you better access to KVO operations.
Upvotes: 0
Reputation: 872
I would say that if you are familiar with Core Data why dont use it?
But alternatively of course you can stick with NSUserDefault. Atm i'm using the NSCache class.
Good explanation of NSCache and how to use it
I would give it a shot if you dont like to use CD for your current Project..
Upvotes: 1
Reputation: 119242
The persistence aspect is only one part of core data. The fetch requests, object graph maintenance and entity modeller are arguably just as important.
If you don't want to persist your data, use the in-memory store type when creating your core data stack.
Upvotes: 3