托管对象与业务对象答案

【问题标题】：managed objects vs. business objects托管对象与业务对象
【发布时间】：2020-01-02 12:02:16
【问题描述】：

我正在尝试弄清楚如何在我的应用程序中使用 Core Data。我已经想到对象图在运行时会是什么样子：

Account 对象拥有TransactionList 对象。
TransactionList 对象包含帐户的所有交易。它不是一个平面列表，而是每天组织交易。因此它包含一个按日期排序的DailyTransactions 对象列表。
DailyTransactions 包含在一天内发生的Transaction 对象列表。

起初我认为 Core Data 是一个 ORM，所以我想我可能只需要两个表：Account 表和 Transaction 表，其中包含所有事务并设置上述对象图（即，按日期组织事务和在运行时使用应用程序代码生成DailyTransactions 对象等）。

然而，当我开始学习 Core Data 时，我意识到 Core Data 更像是一个对象图管理器，而不是一个 ORM。所以我正在考虑使用 Core Data 直接实现上述运行时对象关系（我不清楚有什么好处，但我相信 Core Data 必须具有一些有用的功能）。

所以我正在考虑 Core Data 中的数据模型，如下所示：

Acount <--> TransactionList -->> DailyTransactions -->> Transaction

由于我仍在学习 Core Data，我还无法验证设计。我想这是使用 Core Data 的正确方法。但这不是将太多的实现细节而不是原始数据放在持久存储中吗？我认为保存实现细节的问题在于它们比原始数据复杂得多，并且可能包含重复数据。换句话说，数据模型中的“数据”究竟是什么意思，原始数据或任何有用的运行时对象？

另一种方法是通过定义如下数据模型来使用 Core Data 作为 ORM：

Account <-->> Transactions

并使用应用程序代码设置运行时对象图。这导致更复杂的应用程序代码但更简单的数据库设计（我理解用户在使用 Core Data 时不需要直接处理数据库，但拥有更简单的系统仍然是件好事）。也就是说，我怀疑这不是使用 Cord Data 的正确方法。

一个更普遍的问题。我以前很少做数据库编程，但我的印象是，在像 J2EE 这样的服务器端编程框架中，通常在普通的旧数据对象层之上还有一个业务对象层。在这些架构中，封装应用业务的对象与从数据库加载的对象不同。 Core Data 好像不是这样？

提前感谢您的任何解释或建议。

（注意：上面的例子是一个简化的例子。像转账这样的交易涉及两个账户。为了简化，我忽略了这个细节。）

【问题讨论】：

标签： ios core-data

【解决方案1】：

现在我阅读了有关 Core Data 的更多信息，我将尝试回答我自己的问题，因为没有人这样做。我希望这可以帮助与我有同样困惑的其他人。请注意，答案基于我目前（有限）的理解。

1. Core Data 是一个对象图管理器，用于持久存储数据

网上有很多文章强调 Core Data 管理对象图，它不是 ORM 或数据库。虽然它们在技术上可能是正确的，但不幸的是，它们给像我这样的初学者造成了困惑。在我看来，同样重要的是要指出 Core Data 管理的对象不是任意的运行时对象，而是适合保存在数据库中的对象。合适意味着所有这些对象都符合数据库模式设计的原则。

所以，什么是合适的数据模型在很大程度上是一个数据库设计问题（指出这一点很重要，因为大多数文章都试图让他们的读者忘记数据库）。

例如，在我上面给出的帐户和交易示例中，我想组织每天的交易（例如，将它们放在一个两级列表中，首先按日期，然后按交易时间戳）在运行时。但数据库设计的最佳实践是将所有事务保存在一个表中，并在运行时使用应用程序代码生成两级列表（我相信如此）。

所以Core Data中的数据模型应该是这样的：

Account <->> Transaction

剩下的问题是我可以在哪里添加代码来生成我想要的运行时结构（例如，两级列表）。我认为这是扩展 Account 类。

2。核心数据的约束

Core Data 旨在与数据库一起使用（参见 1）这一事实解释了为什么它对数据模型设计有一些限制（即属性不能是任意类型等）。

虽然我在网上没有看到有人提到这一点，但我个人认为 Core Data 中的关系非常有限。它不能是自定义类型（例如，类），但在运行时必须是变量（对一）或数组（对多）。这使得它的表现力大大降低。注意：我想这是由于某种技术原因。我只是希望它可以是一个类，因此更灵活。

例如，在我的应用程序中，我实际上在 Account 及其 Transaction 之间有复杂的逻辑，并希望将其封装到一个类中。所以我正在考虑引入一个实体来明确表示这种关系：

Account <->> AccountTranstionMap <-> Transaction

我知道在 Core Data 中这样做很奇怪。当我完成我的应用程序时，我会看看它是如何工作的并更新答案。如果有人知道不这样做的更好方法，请告诉我！

3.核心数据的好处

如果一个人正在编写一个简单的应用程序，（例如，一个数据模式更改由用户驱动的应用程序，因此按顺序发生，并且没有来自 iCloud 的异步数据更改），我认为可以忽略所有讨论对象图 vs ORM 等，只使用 Core Data 的基本功能。

从我目前读过的文档来看（还有很多没看完），Core Data 的好处包括自动互引用建立和清理、实时和自动更新关系属性值、撤消等。但是如果您的应用程序不复杂，使用应用程序代码实现这些功能可能会更容易。

也就是说，学习一种具有局限性但同时在更复杂的情况下非常强大的新技术是很有趣的。顺便说一句，只是好奇，在其他平台（开源或商业）上是否有类似 Core Data 的框架？我想我以前没有读过类似的东西。

我将把这个问题留给其他答案和 cmets :) 当我对 Core Data 有更多实践经验时，我会更新我的答案。

【讨论】：