服务层和存储库的职责

Question

我需要一些关于在哪里划清我的服务和存储库的建议。

public class Contact
{
     public Guid Id {get;set;}
     public string Username {get;set;}
     public Guid? AvatarId {get;set;}
     public Avatar Avatar {get;set;}
}

public class Avatar
{
     public Guid Id {get;set;}
     public string FullSizeImagePath {get;set;}
     public string ThumbnailSizeImagePath {get;set;}
}

让我们假设 Avatar 模型将仅用于 Contact 模型，并且它是 Contact 上的可选属性。我的存储库是否应该负责向联系人添加 Avatar，或者业务/服务层是否应该扩展该功能？有人可能会争辩说，拥有头像是一项业务需求，但由于它是模型的一部分，因此数据层应该知道如何处理它。

我建议我们可以通过存储库添加添加/更新和删除头像的功能。业务/服务层将负责保存物理文件、验证和调用存储库上的适当方法。所有存储库关心的是附加适当的联系人并向其添加头像。

我的想法是，由于头像仅用于联系人，目前，我们将扩展存储库，从而为 DAL 添加功能。这可能对单独的 API 有用。

Answer 1

在我看来，我不会将它添加到您的存储库中，而是在您的业务层中定义它。

如果您遵循领域驱动设计，您的 Contact 将获得一个 AddAvatar 方法，该方法将负责创建 Avatar 并设置正确的属性。

仅为聚合根创建存储库。正如您已经声明Avatar 只能通过您的Contact 访问，您的数据层不应包含AvatarRepository。您可以通过相应的联系人加载Avatar。

您还声明 BLL 将负责保存物理文件。我想这个低谷一会儿。你真的想要处理 BLL 中物理文件的代码吗？

假设您出于扩展和备份的原因将 Avatar 文件移至数据库，该代码会突然移至存储库。 存储库是我们在思考过程中立即映射到数据库的东西，但它是数据存储的通用术语，它也可以存储物理文件。我们不介意存储库如何实现这一点。我们关心的是用业务问题编写业务逻辑，而不是担心基础设施问题。

因此，我会将用于创建和更新您的 Avatar 的代码移至您的 BLL，并将用于处理物理文件的代码移至您的 Repository。