Android “如何使用领域”；“生活”；对象并保持数据库层与其他层（业务、UI等）的解耦？

我正在玩Android的Realm

我喜欢自动更新对象的想法，但我对软件架构有一点担心

我已经看到，许多建议的体系结构都指定了一个层来处理数据/数据库访问，理想情况下，更高层将不知道数据库实现的细节。这将有助于维护性、模块化等

当您使用领域对象时，如果您想利用它们的自动更新属性，我能想到的最常用的方法是将这些对象放在活动/片段代码上。现在让我们假设用户刚刚编辑了屏幕上的数据（由引擎盖下的领域对象表示），并正在保存这些编辑。如果您调用这个对象的setter，那实际上是一个数据库操作，您将需要一个事务。通过在活动/片段代码上创建数据库事务，体系结构将崩溃，因为您使UI/业务层了解数据库实现细节

我的问题是：如何在不损害体系结构的情况下利用领域自动更新对象

---

旁注：我在最近的一个应用程序中使用了Realm，对于每个查询，我们都必须将结果复制到非托管对象，以便将它们发送到UI/业务层。我不认为这是最好的策略，因为我们无法充分利用Realm的潜力。

经过一些研究，我得出结论，确实需要在将Realm集成到应用程序时做出一个重大选择：安全集成x深度集成

安全集成

在这里，您将把领域与应用程序代码的其余部分隔离开来。为了做到这一点，您将无法使用领域的自动更新/零拷贝。相反，您将拥有非托管副本，以确保在访问对象的任何位置，不同线程访问相同对象时都不会出现问题。这样测试更容易

深度整合

在这里，您将充分利用Realm的潜力，在请求时延迟加载数据。缺点是代码的其他层会知道领域，从这个意义上说，它们需要确保不同线程不会访问托管对象。如果不启动新应用程序，此选项可能会涉及大量重构，但会带来零拷贝方法的性能优势

---

我的答案基于这些文章：

当然，还有很多很多包装器接口/类。@EpicPandaForce我在你的个人资料中看到你写了很多关于领域的文章。你有没有关于这件事的具体文字？不幸的是没有-这是我个人的路线图，但我一直都有点忙/懒得去做当前要写的“目标”是流，这个主题将在这之后出现。老实说，我更惊讶的是，没有其他人在没有复制每个元素的情况下写过抽象领域。你有没有看一看以获得一些灵感？这篇演讲可能也很有趣：