优化 EF 以使用 DTO 填充表？答案

【问题标题】：Optimizing EF to populate a table using a DTO?优化 EF 以使用 DTO 填充表？
【发布时间】：2014-03-04 01:59:48
【问题描述】：

在尝试在 UI 层上填充网格时，UI 向 BI 层询问结果列表，EF 返回每个结果的列表，然后将它们转换为 DTO，该 DTO 会提取一些附加信息，这是转换成列表返回UI层。

性能太慢了。 EF 正在创建一个新的上下文并针对每个单独的结果访问数据库。这是因为如果 DTO 类不再处于打开/活动状态，则每次初始化时都会创建一个新的 dbcontext。类的终结关闭了上下文。我相信这就是扼杀性能的原因。

有没有办法批量处理这样的事情？在 SQL 中，我会在需要将结果数据加载到数据集中的表上执行 JOIN。在 EF 中，当我创建 DTO 时，我会访问映射的对象关系并访问其他对象的数据。

当我需要访问一些未存储在该特定实体对象中的信息时，我应该如何通过 EF 访问大量记录以将其返回到 UI 层网格？（这方面的一个例子是通过customer_userID-> userID PK在用户->客户之间建立关系。并且想要显示用户名，一旦我有了客户对象，我需要在用户对象中查询用户名与该 ID 的关系。

谁有文章可以指点我正确的方法？

【问题讨论】：

你能告诉我们你到目前为止做了什么吗？正如您所说 - “如果 DTO 类不再打开/活动，则每次初始化时都会创建一个新的 dbcontext” - 你是什么意思？ DTO 从不创建新的 DBContext，它只是简单的“数据传输对象”，它只是移动到应用程序中定义的层。如果可能的话，只需在 UI 端实现分页，对于 DTO，我建议您使用 AutoMapper，例如 this written by Jimmy Bogard
明天会发布一些示例代码。澄清一下，当我需要填充客户对象并将其从 BI 层传递到 UI 层时，我必须启动一个 dbcontext，然后用所有数据填充该对象并将其传递给 UI。然而，更大的选项（比如 1000 条记录）非常慢。（分钟，而不是秒）
在 EF 中，当你第一次启动 DBContext 时，它需要一些时间，因为它会在幕后做很多事情，但是当你下次执行时，它会给你快速的结果.好吧，除了它有任何理由将 1000 条记录传递给 UI 吗？为什么你不使用网格分页？您是否对 EF 的性能进行任何类型的研发？？

标签： asp.net vb.net entity-framework dto

【解决方案1】：

将大量数据传递到 UI 层的函数导致了问题。通常是因为来自 DB 层的对象必须先对其执行一些操作，然后才能将其传递给 UI 层。本质上，一些列表生成功能导致商店为每个单独的请求创建一个新的上下文。

即时分页是一种性能提升，以便请求起始偏移量和记录计数。需要注意的重要一点是，我们必须创建函数来简单地返回总计数，以便 UI 网格知道他们正在处理多少条记录。

下一个修复是在对象被传递到 UI 层之前将 BI 规则应用于对象的函数。在这些情况下，我们打开一个新的上下文并将其传递给函数，因此它会使用该上下文并仅在结果全部完成后将其关闭。

【讨论】：