5 ms·

In defense of Core Data (Part II)

20 points by LinaLauneBaer 12y ago

prodigal_erik 12y ago
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.
- huxley 12y ago
  It's both Mac and iOS: https://en.wikipedia.org/wiki/Core_Data https://en.wikipedia.org/wiki/Core_Data It's not strictly an ORM but more a model-data focused framework that handles the object graph, serialization and persistence.
- threeseed 12y ago
  Actually WebObjects/Project Wonder is still around and kicking. It is a Java port which has an ORM layer that has the same lineage as Core Data. http://wiki.wocommunity.org/display/WEB/Home http://wiki.wocommunity.org/display/WEB/Home
- gress 12y ago
  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 12y ago
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 12y ago
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 12y ago
  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 12y ago
  "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 12y ago
    > 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.

20 points by LinaLauneBaer 12y ago

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.

huxley 12y ago
It's both Mac and iOS: https://en.wikipedia.org/wiki/Core_Data https://en.wikipedia.org/wiki/Core_Data It's not strictly an ORM but more a model-data focused framework that handles the object graph, serialization and persistence.
threeseed 12y ago
Actually WebObjects/Project Wonder is still around and kicking. It is a Java port which has an ORM layer that has the same lineage as Core Data. http://wiki.wocommunity.org/display/WEB/Home http://wiki.wocommunity.org/display/WEB/Home
gress 12y ago
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 12y ago

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 12y ago

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 12y ago
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 12y ago
"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 12y ago
  > 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.