NSCoding VS Core data

问题:

I've been searching for an article that explains NSCoding (NSKeyedArchiver...) advantages and disadvantages over use of CoreData (SQLite....).

There's a lot of options, I can implement my own custom binary reader/writer, or use plists/xml/json... or use SQLite or NSCoding.

I'm kind of lost right now. Can any body explain what's the difference between the MAIN features?

回答1:

It depends which kind of data you want to save and whether you will use it only internally or you have to exchange the data with an external service.

NSCoding is generally speaking a data serializer. A lot of built-in objects implements the NSCoder protocol that allows you to save them as a binary stream (file, in a BLOB of an sqlite, etc.) The NSKeyedArchiver gives you the plus of searching in such streams based on a string label, a bit like a dictionary but you can use only strings as keys. This approach is good if you occasionally have to persist some objects of different classes.

However if you have many objects of the same class, you'll better go for a database-approach, SQLite or CoreData. CoreData is practically a wrapper around SQLite that eases a lot designing your data model, and does the queries to the DB behind the curtains, without the need of writing SQL statements. In CoreData you define your classes, and each instance of the class can be persisted i.e. you can get back the values of the members of the object without having them always in the memory. This is a very convenient way to store a lot of structured data. For example if you'd write a web browser, you could store the bookmarks of the user with the name, URL, and maybe last visited time.

For XML and JSON there're no particular advantage if you use the data only locally to the device. If you have to communicate with some external service, you might consider to cache/save the XML / JSON objects as they are for later use. Other approach would be to regenerate this data from your internal data structures (see above) every time you need it.

If you design your data model yourself, I see even less point to use plists, but maybe somebody will correct me.

EDIT: I add here a short link reference for tutorials on how to use NSCoding, Core Data, and as a bonus, SQLite.

UPDATE 12.01.2016: If you are looking for persistence solutions I suggest you to also check out Realm.

回答2:

Mattt Thompson provides a digestible breakdown of various differences among NSCoding, Core Data, and NSKeyedArchiver on NSHipster: http://nshipster.com/nscoding/

回答3:

There's always an impedance between objects and relational structures. I always prefer objects since data access is typically a fraction of functionality in your app. With NSCoding, you get simplicity, ease of debugging, and control with very little code to write anyways. You also have the flexibility to incorporate NSCoding into your database structures.

NSCoding is a persistence mechanism for saving objects. If you add indexes to your relational structures for search optimization and maintain object structures, then I think you get the best of all worlds at a very low cost and ease of maintenance.

回答4:

To add to already great answers, NSCoding along with NSKeyedArchiver is a great way to store data which is too big (or incompatible data type) for for NSUserDefaults but too small and non-numerous for CoreData.