HN Explorer

9 comments

[ 1.7 ms ] story [ 25.4 ms ] thread
prodigal_erik
Since the article assumes you already know, Core Data seems to be an iOS-only (and I guess MacOS?) ObjC ORM. If you want compile time safety or portability, look elsewhere.
gress
Unless you happen to be targeting iOS or Mac OSX, in which case take core data seriously.

Also, compile time safety is available with generated headers or Swift.

yoda_sl
And to be clear, yes CoreData was launched on Mac OS a while back, and then added to iOS, but CoreData is in fact way older than that. CoreData is a descendant of EOF: Enterprise Objects Framework that was created at NeXT, during the Objective-C days (aka before WebObjects moved to Java).

So Apple has a long history on integrating the ObjC runtime with a back end database. I will be curious to see if something new for CoreData will be coming with Swift.

cageface
Don't put anything in your model code

This is a SERIOUS code smell in my opinion. You want business logic in your model layer. That's where it belongs. A good persistence layer does not dictate model design.

taeric
I think the idea is that this is your persistence model, not necessarily your business model. Often attempts are made to combine these. I feel it is also often that these attempts lead to pain. (And, judging by this blog, I'm not alone. Unless, of course, I'm mistaken.)
shadesandcolour
"Model code" in that sentence refers purely to NSManagedObject subclasses. Create other model objects to work with your entities instead of asking them to do things for you. How much business logic belongs in the class that models a tweet?
sivanmz
> Create other model objects to work with your entities instead of asking them to do things for you.

Regardless of persistence, using such "manager" objects to operate on data records is procedural rather than object oriented programming.