服务层和存储库的责任

我需要一些建议，指出我的服务和存储库在哪里画线。服务层和存储库的责任

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;} 
}

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

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

我的思考过程是，由于头像只在联系人上使用，目前我们会扩展存储库，从而为DAL添加功能。这可能对单独的API有用。

来源

2012-01-18 DDiVita

Offtop，为什么在'Contact'类中需要'AvatarId'属性，因为您可以通过'Avatar.Id'来访问它？ – sll 2012-01-18 18:53:58

@sll我认为这是实体框架（代码优先）所需要的，以帮助定义导航属性Avatar – 2012-01-18 18:55:56

@sll：我将它用于实体框架的导航和映射。我可以告诉EF，数据库中的头像可以为空。 – DDiVita 2012-01-18 19:01:14

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

如果您关注域名驱动设计，您的Contact将得到一个AddAvatar方法，该方法将负责创建Avatar并设置正确的属性。

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

您还声明BLL将负责保存物理文件。我会认为这一段时间。你真的想要处理BLL中物理文件的代码吗？

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

所以，我会将创建和更新Avatar的代码移动到您的BLL以及处理物理文件的代码Repository。

来源

2012-01-18 20:12:16

我从来没有真正想过物理文件通过存储库。完美的感觉！旧的习惯，我想。 – DDiVita 2012-01-18 20:28:41

存储文件是您的基础设施的一部分但确实，旧的习惯:-) – 2012-01-18 20:43:37

服务层和存储库的责任

回答

相关问题