存储库模式与 DTO 模式方法答案

【问题标题】：Repository pattern vs DTO pattern approach存储库模式与 DTO 模式方法
【发布时间】：2012-08-22 20:49:26
【问题描述】：

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

方法 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 中的行为。这两种方法都服务于添加、删除等用户的目的。可以告诉我吗

哪种方法更好？
何时决定我们必须选择以上两种方法中的哪一种？
如果我也必须添加其他方法，例如 FindAllUsers， FindUserByUserId, DeleteUserByUserId 我应该采用哪种方法？

【问题讨论】：

标签： c# java .net oop design-patterns

【解决方案1】：

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

领域驱动设计中经常谈到的最重要的事情之一是“持久性无知”参见What are the benefits of Persistence Ignorance?

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

所以答案：

存储库方法要好得多
始终选择选项 1
将这些方法添加到存储库类中

【讨论】：

+1 补充一点 - 使用存储库模式更清晰 - 存储库添加用户，用户不添加自己.

【解决方案2】：

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

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

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

干杯。

【讨论】：

【解决方案3】：

如果你关注DDD guidelines，那么实体不应该依赖于基础设施：

尼古拉的 IoC 第一定律

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

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

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

【讨论】：