design-patterns - 整洁架构中的实体应该知道持久性机制吗？

Question

在“清洁建筑”(Robert C. Martin)一书中，p。 191，他说“实体是纯粹的商业逻辑，没有别的”。关于持久性机制的实体知识，我不确定我应该如何解释这个陈述。

我假设实体对象是有状态的——它们操纵它们所代表的业务数据。如果是这样，则必须通知持久层对该数据的更改，以便它可以持久保存这些更改。所以;实体是否允许持有对持久性接口(interface)(或工作单元接口(interface)，如果设计更精细)的引用？

我倾向于认为持有这种引用(并从实体内部调用它)的实体对象将不是“纯业务规则”。但我有一种感觉，只要实体持有对接口(interface)的引用，它就不算数？

如果实体不应该引用持久性机制，是否还有其他好的模式可以持久化对业务数据的更改？

Answer 1

关于这个问题有两种主要的思路。它们都由不同的设计模式表示。这两个选项还考虑到您正在处理对业务场景的各个方面进行建模的有状态实体，从这个意义上说，它们知道将要持久化的“数据”，但是它们不一定知道持久性机制本身.

现在，关于持久性机制，第一种方法可能是老 J2EE 或 Rails 从业者最熟悉的，其中实体完全知道它将被加载/保存到底层持久性中，并且它的接口(interface)将传达这样的方法“获取”、“插入”、“更新”。这被称为“事件记录”(Martin Fowler，企业应用程序架构模式)模式。也就是说，实体在对您的业务的一个方面进行建模时，它也将代表数据库中的直接记录，并且能够自行保存/加载。

另一种方法更符合您提到的“清洁架构”，一些作者将其称为“数据映射器”(也是 Martin Fowler，企业应用程序架构模式)模式。在这件事上，实体仍然不知道持久性机制(它将是“纯业务逻辑，仅此而已”)，并且您将“映射”实体的“数据”的责任委托(delegate)给外部参与者(类/其他)目前持有和退出持久性机制/层。

换句话说，当采用这种方法时，您将把理解持久性机制以及从数据库到实体以及从实体到数据库进行翻译的责任委托(delegate)给翻译人员。这样，您的实体甚至都不会意识到它们被持久化在其他地方，更不用说这种持久化过程的内部运作了。

持久性数据映射器的接口(interface)将大致如下:

interface IMyDataMapper {
    void Save(IMyEntity entity);
    IMyEntity Get(whatever criteria you use to find the entity);
}

所以，从那个接口(interface)来看，它的职责很明确:

它接收一个实体(它不知道此操作)并读取其数据以将其存储在其他地方。

它接收标准以在其他地方查找存储的数据，找到它并使用此数据填充实体对象以将其返回给您。