存储库模式和服务层实现

本文关键字：实现 服务 模式 存储 | 更新日期: 2023-09-27 18:15:51

我正在为我的mvc4网站使用通用存储库和工作单元模式。

现在我有这样的情况，我想删除系统中的一个用户。在删除代码中，我必须删除其他表中的一些条目(注释，访问权限，…)。

最简单的解决方案是创建一个继承GenericRepository<User>的UserRepository，并修改delete方法来删除其他表中的数据。但这意味着我的UserRepository将访问其他表，这些表应该有自己的存储库类，对吗?

我读过关于服务层的文章，它位于我的业务逻辑和存储库之间。

这里的最佳实践是什么?服务层的实现看起来如何?

如果我使用服务层，是否仍然有自定义实现的存储库(如UserRepository)的任何要求，或者我应该只有通用存储库并在服务类中执行逻辑?

示例代码:

class UserRepository
{
    public void Delete(User entity)
    {
        var userComments = Context.UserComments.Get(comment => comment.UserId == entity.Id);
        foreach (var comment in userComments)
        {
            Context.UserComments.Remove(comment);
        }
        //
        // same for access rights here
        //
        Context.Users.Remove(entity);
    }
}

存储库模式和服务层实现

存储库模式随着DDD(领域驱动设计)运动而普及。在DDD中，建议不要为每个表创建一个存储库，而是为每个聚合根创建一个存储库。因此，虽然您可能有一个用户、用户订单和用户评论的表，但您可以决定user是一个聚合根，然后您只需创建一个用户存储库并在那里添加您的方法。

无论如何，不管你是否关心DDD，我都会将逻辑添加到你的用户repo中，它在那里比其他任何repo都有意义。

你可以创建一个服务层，并为此创建一个服务类，但是服务类对这个并没有什么用处——在这种情况下你并没有得到任何好处。

使用

.WillCascadeOnDelete(true);

on modelBuilder

回答您关于服务的问题。理想情况下，您希望服务对存储库为您检索的实体/对象执行额外的逻辑。在这种情况下，您实际上不希望服务删除行，因为这是存储库的责任。

服务很好。在MVC中，你从控制器调用服务方法。理想情况下，接口可以方便地进行测试。

正如您所说，服务层可以帮助您分离业务逻辑和存储库。这里的主要思想是依赖注入

public interface IUserService
{
    public void Delete(User entity);
}
//
// This class would be used Linq to Entities 
public class LinqUserService : IUserService 
{
    public void Delete (User entity)
    {
    }  
}
// 
// This class would be used Sql command
public class SqlUserService : IUserService
{
    public void Delete (User entity)
    {
    } 
}
相关文章：