1

我试图保持我的实体持久性和服务无知，但是当涉及到实体的 BLOB 和文件对应属性时，我遇到了障碍。假设我在聚合中有一个像这样的实体（例如保持基本）：

class Attachment
{
    private $_ownerId;
    private $_filename;
    private $_type;
    private $_size;

    public function __construct ($ownerId, $filename, $type, $size)
    {
        $this->_ownerId = $ownerId;
        $this->_filename = $filename;
        $this->_type = $type;
        $this->_size = $size;
    }

    // some getters, etc.
}

我已经考虑或正在考虑的方法：

  1. 创建一个服务接口，'FileProvider' 或类似的方法load (Attachment $file)，其实现者知道如何获取和返回文件的二进制文件
    • 这允许数据访问逻辑的多种实现（FileProviderMysql、FileProviderDirectory、FileProviderRemoteFTP 等）
    • 这似乎符合 Eric Evans 将服务类描述为封装了似乎不适合实体或值对象的行为的对象
    • 在 Evans 的书中也有示例，其中服务类使用简化的、意图揭示的接口封装对笨拙或遗留接口的访问
  2. 可能将所述接口的实现注入实体本身，以便可以使用与其任何其他属性相同的语法即时获取实体的内容
    • 这样，聚合的存储库（或其当前策略）将能够注入与当前存储实现相对应的服务实现，从而使客户端和应用程序服务免于进行该调用
    • 但是，我不确定实体是否应该真正“了解”服务接口

在这种情况下有经验的人可以权衡一下并帮助我做出决定吗？我想确保我正在做的工作能够坚持下去。谢谢...

4

1 回答 1

2

我会采用方法 1，它可以是域服务或存储库。无论哪种方式，对与 Attachment 对应的 BLOB 的访问都会被封装。

考虑您需要访问 BLOB 的点也很重要。任何与域相关的行为都需要它吗？还是更多的是基础设施问题？

更新

方法#2 的好处是增加了对与实体相关的行为的封装。如果在这种情况下Attachment引用了用于加载 blob 的服务，则可以在不需要额外依赖项的情况下传递该实体。这似乎也是一种更自然的方法。既然Attachment实体提供对其他字段的访问，为什么不提供 blob？

然而，这种方法有几个缺点。通常不鼓励让实体引用服务或存储库，因为它可能导致职责交叉，并且使对实体行为的推理更加困难，尤其是在依赖项本身是抽象的情况下。相反，最好确定需要 BLOB 的用例，并在实现这些用例的代码中引用此服务，通常是周围的应用程序服务。

于 2013-01-23T17:34:22.573 回答