0

This is similar to a question I asked before, but now that I've come much further along I still have a question about "proper" subclassing of NSManagedObject as I was told last night that it's a "bad idea" to put lots of non-persisted properties and ivars inside one. Currently I have TONS of code inside my NSManagedObject, and Apple's docs don't really address the "rightness" of that. FYI: the code works, but I'm asking if there are pitfalls ahead, or if there are obvious improvements to doing it another way.

My "object" is a continuously growing array of incoming data, the properties/ivars that track the progress of the analysis of that data, and the processed data (output). All of this is stored in memory because it grows huge, very quickly, and would not be possible to re-generate/re-analyze continuously. The NSManagedObject properties that are actually persisted are just the raw data (regularly saved, as Core Data doesn't support NSMutableData), a few basic properties and 2 relationships to other NSManagedObjects (1 being a user, the other being a set of snapshots of the data). Only one object is being recorded to at any one time, although dozens can be opened for viewing (which may involve further processing at any time).

It's not possible to have the object that inserts the entity (data manager that manages Core Data) have all of the processing logic/variables inside it, as each object necessitates at least a handful of arrays/properties that are used as intermediaries and tracking values for the analysis. And I, personally, think that it sounds silly to create two objects for each object that is being used (the NSManagedObject that is the store, and another object that is the processing/temp store).

Basically, all of the examples I can find using NSManagedObjects have super simple objects that are things like coordinates, address book entries, pictures: stuff that is basically static. In that case I can see having all of the logic that creates/modifies them outside the object. However, my case is not that simple and I have yet to come up with an alternative that doesn't involve duplication.

Any suggestions would be appreciated.

Adam Jones
  • 775
  • 6
  • 23

1 Answers1

1

You might use a 'wrapper', that is to say a class with a reference to one of your managed object instances, this wrapper would contain your algorithms and your non persisted algorithms.

Jerome Diaz
  • 1,746
  • 8
  • 15
  • First, that you said, "algorithms and your non persisted algorithms" makes me thing I didn't explain myself well enough. The only persisted data is the raw data. However, while the object is loaded (recording or reading back / re-analyzing) there is a large amount of additional properties and arrays that must exist as well and are unique to each object (they are directly related to -that- specific data). Second, can you explain how you feel adding an additional layer would help? An explanation of why you think it would be better, for instance. – Adam Jones Mar 21 '13 at 00:31
  • with an additional layer you wouldn't need to put all those "bad" elements in your NSManagedObject subclass. As you've already been told, NSManagedObject is to store persistent data, you shouldn't put other things there (even if nothing really prevent you from doing so, but it is quite ugly). I propose you to have one wrapper instance for one managed object, and to use KVO (Key value observing) in your wrapper to be notified of raw values being updated. – Jerome Diaz Mar 21 '13 at 09:18
  • Done. If one assumes NSManagedObjects are just persisted data and not a "living" object, then I can see the desire to break the two apart. – Adam Jones Mar 22 '13 at 14:28