LINQ toEntity - 传递模型的最佳实践

Question

众所周知，大多数应用程序都有一个数据访问层，通常使用存储库类。通常，我们希望存储库能够使用强类型对象进行操作，例如，

interface IUserRespository
{
     User GetUserByID(int id);
     void AddUser(User u);
     ... and so on
}

但是，有时我们希望对数据库进行更复杂的查询，这涉及分组和聚合。例如，我们要获取所有用户的所有订单的总值（结果集只有两列：UserName 和 TotalAmount）。现在我的问题：存储库方法是什么样的？ LINQ toEntity 网上有很多关于如何使用 sum 和 group by 进行查询的示例，但所有这些示例都返回匿名类型。那么，我们的存储库如何返回此类查询的结果呢？另一个常见的答案是：将其包装在一个类中。因此该方法可能如下所示：

interface IUserRepository
{
    UserOrderTotal[] GetOrderTotalsForAllUsers();
}

UserOrderTotal 必须是一个小类，具有查询返回的两个属性：UserName 和 TotalAmount。该类将在我们的 .cs 文件之一中的某个位置定义。这真的是唯一的解决方案吗？它看起来非常糟糕，因为它在主要实体模型（edmx）之外的某个地方引入了一个新的“临时”模型。理想情况下，我想用一个名为 TotalAmount 的新字段来丰富我的 User 模型，该字段仅在此查询中填充，因此界面可能如下所示：

interface IUserRepository
{
    User[] GetOrderTotalsForAllUsers();
}

它将返回所有字段设置为默认值的 User 实体，除了名称和总金额。我遇到的问题是，我无法编译具有未映射到数据库列的字段的模型。我收到错误 错误 3004：从第 2226 行开始的映射片段出现问题：没有为 Set User 中的属性 User.TotalAmount 指定映射。当以下情况时，带有密钥 (PK) 的实体将不会往返：实体类型为 [FPSoMeterModel.User ]

我做错了吗？这个问题是微不足道的，还是我问了错误的问题？为每个涉及聚合的查询（！）创建一个包装类似乎有点荒谬。看起来整个 LINQ 的东西鼓励人们不要使用多层架构，而是在呈现数据的同一层中构建查询......你们如何处理这个问题，你们是否使用“存储库”类LINQ，如果是的话 - 如何返回复杂的查询结果？

Answer 1

相反，我不认为定义新的 UserOrderTotal 类是不好的做法。有两种看待这样一个物体的方法。

(1) 您可以将此 UserOrderTotal 类视为数据传输对象（DTO）。这样它就不是您的域的一部分。 DTO 通常用于通过线路传输实体或以扁平形式向表示层提供域对象。我一直在使用它们。在这种情况下，对象被用作数据上的投影：作为视图。 MVVM 模式使用相同的原理，其中 MVVM 的 ViewModel 部分是用户界面特定的 DTO。

(2) 您可以将此 UserOrderTotal 类视为域的一部分。从领域驱动设计的角度来看，对象可以是用户语言的一部分。在这种情况下，将其定义为域对象是合乎逻辑的结果。但不同之处在于，它不会在实体框架 (EF) 的 edmx 文件中定义。我认为在 EF 中可以定义没有映射到数据库表的实体，但我不知道这是否会让事情变得更容易。我个人认为在 edmx 文件所在的同一项目中的 edmx 文件外部定义这些域对象没有问题。

关于返回 User 对象数组：这似乎是一个坏主意。这种方法存在几个问题。首先，您的代码没有很好地传达其意图。您使用 User 对象，但将所有属性留空。对于任何尝试使用此代码的人来说，这种做法很难遵循。实际上，您正在滥用 User 对象来实现它不是的东西：即聚合。

除此之外，您注意到 EF 无法处理您添加到模型中的这个额外属性。虽然通常可以向 EF 模型添加属性（通过使用部分类），但您对此应该非常保守。当您在 LINQ 查询中使用这些属性时，虽然可以编译，但在运行时会失败。

为每个查询创建一个包装类
(!) 涉及聚合似乎是
有点可笑。

我不这么认为。 IMO 这是正确的做法。这是在多层架构中使用 EF 的结果。我必须承认，在单层中使用 EF 会容易得多，但从长远来看，它会变得非常混乱。项目越大，需要维护的时间越长，添加抽象层就越合理。

你们是如何处理这个问题的？
将“存储库”类与 LINQ 结合使用

我设计的应用程序通常有一个服务/业务层，用于将读取与突变分开。对于读取操作/查询，我使用静态类以及返回域对象或 DTO 集合的方法。通常，这样的“服务方法”特定于用户界面的特定部分。这些突变包含在“服务命令”中。用户界面创建服务命令并触发它。命令表达单个用例或用户故事，并且是逻辑的原子部分。服务层将确保在执行命令时创建数据库事务（在需要时）。对于用户界面，使用命令通常如下所示：

void UpdateButton_Click(object sender, EventArgs e)
{
    if (!this.Page.IsValid)
    {
        return;
    }

    var command = new UpdateUserSettingsCommand();

    command.UserName = this.UserName.Text;
    command.MailAddress = this.MailAddress.Text;

    command.Execute();
}

我希望这一切都有意义。如果您想了解有关我如何使用 DTO 的更多信息，请阅读此所以我的回答。

我希望这有帮助。