使用实体框架返回要迭代的数据表答案

【问题标题】：Using Entity Framework to return a table of data to iterate against使用实体框架返回要迭代的数据表
【发布时间】：2019-05-09 12:02:18
【问题描述】：

我目前正在使用 EF 6 执行以下操作。执行一个存储过程，然后带入我需要使用的数据。每个应用程序运行的数据通常为 30-40 行。

然后我遍历 var、object、table（无论你想怎么称呼它），在每一行上执行类似（有时不同）的任务。它工作得很好。我能够创建一个 Entity 对象，公开它的不同复杂功能，然后创建一个 var 进行迭代。

喜欢：

foreach (var result in StoredProcedureResult)
{
string strFirstname = result.FirstName
string strLastName = result.LastName
//more logic goes here using those variables and interacting with another app

}

我最近认为如果我有一个专门用于访问数据的类会很酷。这样，我可以只引用那个类，将相应的连接字符串扔到我的 app.config 中，然后我可以将两组逻辑分开。因此，当尝试在该结构中执行上述操作时，我会遇到无法返回 var 或尝试匹配对象返回类型的点。存储过程执行的返回类型是对象（我无法迭代）。

所以我的问题是，除了 var 结果之外，如何从这个数据访问类返回上述示例？

如果我遗漏了什么，或者因为我做错了而无法做到，请告诉我。它就出现在我的脑海中。

【问题讨论】：

你看过 EF 中的函数导入吗？
@Marty 嘿，感谢您的回复。我的印象是我已经在使用函数导入了？这不是上面代码 sn-p 的结果吗？ StoredProcedureResult 来自执行以下操作：EntityName db = new EntityName(); var StoredProcedureResult = db.Sp_That_Returns_SomeRows_And_Columns(); db.Dispose();
首先：如果 EntityName 是 DbContext 的类名，那么更常用的方法是使用 using 而不是 Dispose see doc。第二：函数导入应该允许您指定过程返回一个复杂类型，这样您将返回该类型而不是对象
@Marty 好的，将其包装在 using.hmm 中，它看起来确实在下拉菜单中设置为“复杂”。所以完全限定类型 VS 调用它是：System.Data.Entity.Core.Objects.ObjectResult
@Marty 很好，上面似乎解决了返回类型问题，ObjectResult 是一个可以迭代的返回类型。还有一个小问题。因此，在我以返回名字或姓氏为例的帖子中，您可以看到为特定列创建了 get 和 set，并且在 DataAccessLayer 中我可以看到这些方法。问题是，在引用 DAL 的项目中，string strFirstname = result.FirstName 在您键入 result. 时没有显示列列表的智能感知，所以我想我一定在这里遗漏了一些东西。

标签： c# entity-framework data-access-layer

【解决方案1】：

我不会完整地描述架构。但是根据您的 cmets，您可以执行以下操作（这不是最终的方法，也不是唯一的方法）：

在您的数据访问项目中，您保留 DBContext 类、存储过程调用的所有代码以及定义 SP 调用结果的类，我们称之为 A 类；
在您的共享层项目中 - 我建议将其称为服务层 - 您可以创建一个 XYService 类，它有一个方法，例如GetListOfX 连接DB并调用过程，如果需要这个方法也可以执行一些逻辑，但更重要的是：它不返回类A，而是返回一个新的类B（这个定义在服务层，或者可以在另一个项目中定义——这可能是真正的共享/公共项目；因为它只是对公共结构的定义，它并不是真正的层）；
在您的应用程序层中，您只能使用 XYService 和 B 类的方法 GetListOfX，这样您就不需要对数据访问项目的引用

在一个简单的情况下，B 类具有与 A 类相同的属性。但是根据您的需要，B 类可以具有其他属性/功能，它也可以忽略 A 的某些属性，甚至可以将多个属性合并为一个：例如将FirstName 和LastName 组合为一个属性，简称为Name。

基本上您正在寻找的是多层应用程序架构（通常是 3-4 层）。根据您的目标，这种方法的全部范围（包括大量使用接口和依赖注入等概念）可能不适合或不需要，例如如果您只是为自己构建一个带有几个功能的小型应用程序，或者您知道最终解决方案的组件不会有任何重用，那么这种方法太浪费了，您可以在一个项目中更快地处理所有内容 -您仍然应该遵循SOLID、DRY 和Separation of concerns 等原则。

【讨论】：

实施了这个解决方案。有了你的阅读链接和很好的解释，我想我现在已经开始制作一个体面的分层应用程序了。这不是我应该做的，更多的是我能做的。在这个帮助下，我能够做到。谢谢马蒂！
我认为我唯一可能偏离您的方向的地方是第一步。我的数据层看起来更像是一个服务类，只有使用 EF 调用 SP 然后返回结果的方法。我认为这与您所说的有点不同：存储过程调用的所有代码以及定义 SP 调用结果的类
@MikeCMR 有多种使用 EF 的方法，在简单的情况下，您甚至不需要 SP，并且可以使用 LINQ 查询表，如果您还没有看过它，我会建议您阅读它；）