CODEWITHSUNDEEP
ioscore-data
wujek
wujek

Reputation: 11040

CoreData, unrelated data per module - one stack or per module?

In our application, we currently have the need to store data of different 'modules', completely unrelated. We want to use Core Data for this. As far as I can say, we have a few options:

  1. create multiple model descriptions (one for each 'module'), and use separate Core Data stacks for each 'module'
  2. create multiple model descriptions as in #1, but use a single CD stack (I think it is possible for a single coordinator to encompass multiple modules by using 'configurations')
  3. create a single model description with one configuration which will contain all the entities, and use a single stack
  4. possibly more variations of the above...

Additionally, all of these options can be used with a single managed object context or with multiple ones.

What would be the best way to go?

I would tend to use option #1, i.e. separate model description files, separate coordinators, separate contexts, because as said before, the 'modules' are completely unrelated and it would actually be an error if one 'module' did something with entities from another. It is also possible that module data will be versioned / migrated separately / at different times than for other modules, although we have no need / use case for this yet. (I also don't know how CD versioning works, i.e. is some kind of version set for the whole model, or just for each entity separately? If the former, splitting into multiple model could be an advantage).

But maybe using option #1 is too much and overcomplicating / overengineering things, and I should just not care and put all into one bag?

Upvotes: 1

Views: 199

Answers (1)

Mundi
Mundi

Reputation: 80265

Here is some help for your decision:

  1. If the modules are to a large extent similar, I think replicating the same or almost same model information would be too redundant. I this case I would prefer #2.
  2. You can use multiple stores. However, this does add some complexity to your project. Depending on the overall size of your data, multiple stores could make sense. If the data volume is limited, there is no reason not to just use one store.
  3. The usual use case for multiple stores is to have one read-only with static data, and one that is dynamic to which you can write. I would think that large different data sets that would hit performance if they were in the same store is also a good reason to use multiple stores.
  4. Migration is not really a problem. In CD you can create new entities and attributes, change their behaviour, copy data from one to the other, etc. You will have very granular control over the migration, so this would not change in either scenario.
  5. In my opinion the fear of "mixing up" data that should never be mixed is not a valid one. The logic in your program should ensure the correct functionality regardless of your architecture choice.

Upvotes: 2

Related Questions