How does Core Data fit into MVC model objects?

Question

This is more of a theoretical question, but how does/should Core Data objects fit into an application's "model"? At the simplest level, the "model" could just be the Core Data objects directly, but by themselves, they are just data containers without any kind of "observable" functionality. There could be a separate model class that encapsulates the core data objects, which seems like a better solution, but I'm not really sure if the references should be strong or weak.

Also, should the Model be concerned with and/or handle its own persistence?

Answer 1

In the context in which Apple uses the MVC idiom, core data by itself absolutely qualifies potentially for the entire data layer.

Managed Object subclasses can contain a lot of functionality - what you call model "logic". That is a perfectly common design pattern. For example, if your data model describes transaction data with dollar values, you can have fetch request templates that deliver sums of those values. You can do even more complicated things by extending your managed objects with custom methods delivering calculated / formatted etc. data.

In your controllers then, you can read and change the data, and get input from the UI and update the display of the data. Your controllers should not really do much more than that.

Of course, in the case of extremely complex application logic, you can always create a singleton like DerivativesTradingProfitabilityEngine that can crunch the data from Core Data and feed it to the UI controllers. This might be suitable if you need to to a lot of heavy lifting in background threads.

In most cases, however, the standard Core Data setup is sufficient.