这更像是一个理论问题，但核心数据对象如何/应该如何适应应用程序的“模型”？在最简单的层面上，“模型”可以直接是核心数据对象，但它们本身只是没有任何“可观察”功能的数据容器。可能有一个单独的模型类来封装核心数据对象，这似乎是一个更好的解决方案，但我不确定引用应该是强还是弱。
此外，模型是否应该关注和/或处理自己的持久性？
问问题
1410 次
1 回答
8
在 Apple 使用 MVC 习语的上下文中，核心数据本身绝对有资格用于整个数据层。
托管对象子类可以包含很多功能——你称之为模型“逻辑”。这是一种非常常见的设计模式。例如，如果您的数据模型使用美元值描述交易数据，您可以使用获取请求模板来提供这些值的总和。您可以通过使用提供计算/格式化等数据的自定义方法扩展托管对象来做更复杂的事情。
然后，在您的控制器中，您可以读取和更改数据，并从 UI 获取输入并更新数据的显示。你的控制器不应该做更多的事情。
当然，在极其复杂的应用程序逻辑的情况下，你总是可以创建一个这样的单例DerivativesTradingProfitabilityEngine，它可以处理来自 Core Data 的数据并将其提供给 UI 控制器。如果您需要在后台线程中进行大量繁重的工作，这可能是合适的。
然而，在大多数情况下，标准的 Core Data 设置就足够了。
于 2013-06-25T16:54:05.527 回答