仓储模式与 DTO 模式的比较方法

Question

我们可以采用两种方法将数据发送到数据访问层或其他数据源： 方法一：仓库方式（Repository way）：

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，我应该选择哪种方法？

- Rocky Singh

Answer 1

第一种方法更好，因为您正在分离关注点，即领域实体“User”和对数据库的持久性。

在领域驱动设计中，经常谈论的最重要的事情之一是“持久性无知”（persistence ignorance）请参见持久性无知有哪些好处？

通过使用存储库模式，您保存/获取实体的方式被保留在实体代码之外，即您的领域保持更加清洁，并在本质上实现了持久性无知（或者至少大大接近它）。

所以回答如下：

1. 存储库模式更好
2. 始终选择选项1
3. 将这些方法添加到存储库类中

- bstack

---

补充一下，使用仓储模式会更加清晰明了——仓储会“添加”用户，而不是用户自己“添加”。 - James

Answer 2

这严格取决于您需要完成的工作以及您的应用程序规模。如果您想快速开发并且不太可扩展，那么您无需使用 n 层类型架构（我的意思是将数据交互分离到数据访问层中）。

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

最后，正如我所说的，每种方法都有其用途，在开始工作之前请了解您的目的。

干杯。

- Freeman

Answer 3

如果你遵循DDD指南，则实体不应该依赖于基础设施：

Nikola的IoC第一定律

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

原因：将基础设施逻辑包含到实体中，会偏离单一职责原则。请参见Mark Seemann的解释。

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

- Hooman Bahreini