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上的可选属性。我的存储库是否应该负责向联系人添加头像，或者业务/服务层是否应该扩展该功能？有人可能会说拥有一个化身是一个商业要求，但由于它是模型的一部分，数据层应该知道如何处理它。

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

我的思维过程是因为化身仅用于联系人，目前，我们会扩展存储库，从而为DAL添加功能。这对于单独的API可能很有用。

Answer 1

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

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

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

您还声明BLL将负责保存物理文件。我会想到这个问题。你真的想要在你的BLL中处理物理文件的代码吗？

假设您将Avatar文件移动到数据库以进行缩放和备份，该代码会突然转移到存储库。存储库是我们在思考过程中立即映射到数据库的东西，但它是数据存储的通用术语，它还可以存储物理文件。我们不介意Repository如何实现它。我们关心的是编写业务逻辑，解决业务问题，而不是担心基础架构问题。

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

服务层和存储库的责任

1 个答案: