This looks cool. Data modeling in Cocoa has, historically, been kind of terrible. It doesn't look like there's a solid story for persistence yet, though (i.e. writing data to sqlite). Is that accurate or am I missing something?
I don't see storage integration as a default. The example talks about having free conformance to the NSCoding interface so you can archive it that way if you don't need the relational baggage. [1] and [2]
Though, there is nothing stopping you from writing your own layer that uses the models here to read and write to another backing store like sqlite.
Wouldn't it make more sense for the first comparison in the docs to be with core data? It is the point of reference in cocoa for model data and persistence and is much simpler than the example given, so ignoring it till the end seems a little disingenuous... Looks interesting though, I'm off to read further.
In addition, their comments about Core Data multithreading are flat out wrong. The whole point of queued contexts in iOS 5/OS X 10.7 was to do away with the whole mess of passing IDs between threads. It works quite well, although as always, there is a vocal minority who never completely grokked Core Data and hate on it when they encounter bugs in their implementation along the way.
What's with the categories? They don't seem to be used in either of the primary .m files (cmd+f "mtl"), so they aren't really needed. Do one thing well.
If you want to make a higher order function library, that's fine, but I don't see what it has to do with mapping data to JSON, and I don't think that users of the library should have to get a bunch of modifications to the standard container classes to get the nice model class. Why not split it into two libraries?
5 comments
[ 2.7 ms ] story [ 17.2 ms ] threadThough, there is nothing stopping you from writing your own layer that uses the models here to read and write to another backing store like sqlite.
1. https://developer.apple.com/library/mac/#documentation/Cocoa...
2. http://www.raywenderlich.com/1914/how-to-save-your-app-data-...
If you want to make a higher order function library, that's fine, but I don't see what it has to do with mapping data to JSON, and I don't think that users of the library should have to get a bunch of modifications to the standard container classes to get the nice model class. Why not split it into two libraries?