How does Core Data fit into MVC model objects?

Question

This is more of a theoretical question, but how / should Core Data objects fit into the "model" of the application? At the simplest level, a “model” can be directly Core Data objects, but in itself they are only data containers without any “observable” functionality. There may be a separate model class that encapsulates basic data objects, which seems like the best solution, but I'm not sure if the links should be strong or weak.

In addition, should the Model account for and / or process its own persistence?

Answer 1

In a context in which Apple uses the MVC idiom, kernel data alone can potentially claim the entire data layer.

Managed object subclasses can contain a lot of functionality - what you call the model "logic." This is a completely general design template. For example, if your data model describes transaction data with dollar values, you can get fetch request templates that provide sums of these values. You can do even more complex things by expanding your managed objects with custom methods that provide computed / formatted data.

Then in your controllers you can read and modify data, as well as receive input data from the user interface and update the display of data. Your controllers should not do much more.

Of course, in the case of extremely complex application logic, you can always create a singleton, such as DerivativesTradingProfitabilityEngine , which can crunch data from Core Data and pass it to the user interface controllers. This can be convenient if you need a lot of hard work in the background.

In most cases, however, a standard Core Data installation is sufficient.