c# - 存储库模式与 DTO 模式方法

Question

我们可以使用这两种方法将数据发送到数据访问层或任何其他来源：

方法1：存储库方式：

public class User
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

public class UserRepository
{
    public static void Add(User user)
    {
        // Add user logic
    }
    public static void Delete(User user)
    {
        // Delete user logic
    }
    public static User Get(int userid)
    {
        // Get user logic
    }
}

用法：

var user = new User
    {
        FirstName = "FirstName",
        LastName = "LastName",
        Age = 20
    };
UserRepository.Add(user);

在上面，您已经看到我使User类保持简单。它没有任何行为。行为被添加到单独的类UserRepository中。

第二种方法：仅在 User.cs 中保留 Add/Delete/Get 等：

   public class User
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }

        public void Add()
        {
            // Add user logic
        }
        public void Delete()
        {
            // Delete user logic
        }
        public User Get()
        {
            // Get user logic
        }
    }

用法：

var user = new User
    {
        FirstName = "FirstName",
        LastName = "LastName",
        Age = 20
    };
user.Add();

上面我只保留了 User.cs 中的行为。这两种方法都服务于添加、删除等用户的目的。你能告诉我吗

1. 哪种方法更好？

2. 何时决定我们必须选择上述两种方法中的哪一种？

3. 如果我也必须添加其他方法，例如FindAllUsers、 FindUserByUserId、DeleteUserByUserId我应该采用哪种方法？

Answer 1

第一种方法要好得多，因为您要分离关注点，即域实体用户和数据库的持久性。

领域驱动设计中经常谈论的最重要的事情之一是“持久性无知”请参阅持久性无知的好处是什么？

通过使用存储库模式，您保存/获取实体的方式不受实体代码的影响，即您的域保持它更清洁，并且实质上实现了持久性无知（或者无论如何都要走很长的路）

所以回答：

1. 存储库方法要好得多
2. 总是选择选项 1
3. 将这些方法添加到存储库类

Answer 2

这完全取决于您需要完成的工作以及应用程序的大小。如果您想要快速开发且可扩展性较低的东西，则不需要使用 n 层类型架构（我的意思是将您的数据交互与您的数据访问层分开）。

但是，如果您正在寻找需要高度可扩展、可编辑、可修改的东西，并且知道它将获得未来的功能，那么显然您必须分开您的关注点，以使您的工作在更长的时间内更容易。

最后，正如我所说，每种方法都有一个目的，在开始工作之前就知道你的目的是什么。

干杯。

Answer 3

如果您遵循DDD 指南，那么实体不应依赖于基础设施：

尼古拉的国际奥委会第一定律

仅存储在 IoC 容器中的服务。不要存储任何实体。

原因：通过将基础架构逻辑包含到您的实体中，您正在远离单一职责原则。参见 Mark Seemann 的解释。

您的第二种方法的问题是User实体依赖于基础设施。