将 OData 语法与 WebAPI 和 DAL 结合使用答案

【问题标题】：Using OData syntax with WebAPI and DAL将 OData 语法与 WebAPI 和 DAL 结合使用
【发布时间】：2015-07-07 16:34:10
【问题描述】：

我目前在与我的主项目不同的项目中拥有一个数据层、容纳 EF 和一个存储库模式。我现在想对查询实现分页和过滤，并发现 WebAPI 具有 OData 查询支持。

这个问题可能只是因为我是新手，但如果我使用来自项目控制器的 OData 查询，难道我的 DAL 项目几乎没有必要吗？我这么认为的原因是因为存储库的接口必须公开 IQueryable，而不是集合列表。

我有一个单独的数据层的原因是我正在尝试为我的公司创建一个 Intranet 系统，并且会有很多用户同时访问数据库。该层（我相信）将有助于在未来扩展系统以及数据库请求，并通过创建方法库来消除我的控制器中的重复请求。

在存储库中公开 IQueryables 不是很理想吗？还是我什么都不担心？

【问题讨论】：

标签： c# entity-framework asp.net-web-api odata

【解决方案1】：

您应该完全从 DAL 中将您的实体集公开为 IQueryable。

据我了解，您的 DAL 包装了 EF 上下文并使用存储库模式将您的实体公开为 IEnumerable/ICollection ？如果是这种情况，那么当您将实体公开为 IQueryable 时，查询的性能将显着提高。

如果我使用来自项目控制器的 OData 查询，是不是我的 DAL 项目几乎没有必要？

您不应该在控制器中保留负责从/向数据库接收/发送数据的逻辑，因此 DAL 项目中的存储库仍然有用。

说明： 在性能方面，您应该记住，只要您在 IQueryable 上进行操作，您实际上就是在对 SQL 查询进行操作，一旦您使用 ToList() 将其具体化，您就会对数据库执行请求并开始对数据进行操作来自系统内存。

关于从存储库中公开 IQueryable： 与 ICollection 相比，您不仅获得了改进的性能，还摆脱了许多特定的数据获取方法（如 GetAllActiveUsers、GetAllInactiveUsers 等），从而为存储库的使用者提供查询特定数据的可用性，在某些情况下可能是一个问题，因为它可能会被他们滥用。但是，我不认为这对您来说是个问题，因为我假设您并没有在大型开发团队中开发大型应用程序。

示例：因此，假设您有一个实体“用户”和 UserRepository 类。您想在 Email 属性中接收非空值的用户集合，因此您想出了以下代码：

var users = _userRepository.Users.Where(x => x.Email != null).ToList();

在将用户公开为 IEnumerable/ICollection 的情况下，您会从数据库中返回所有用户，然后将集合放在系统内存中，您可以在其中搜索不为 null 值的用户电子邮件属性。在这种情况下，由 EF 生成并发送到数据库的查询类似于 SELECT * FROM [schema].[User]
在将用户公开为 IQueryable 的情况下，您将返回电子邮件属性中已从数据库中具有非空值的所有用户。在这种情况下，由 EF 生成并发送到数据库的查询类似于 SELECT * FROM [schema].[User] WHERE [Email] IS NOT NULL

【讨论】：

我知道您希望将发送/接收逻辑分开，但至少在我看来，当您公开 IQueryable 时，这意味着我的控制器实际上会进行查询，对吧？我只是看起来我的 DAL 就像一个直通隧道，通过我的查询参数传递我可以在控制器中声明的 IQueryable？
你的控制器只是客户端，告诉你的 DAL 类似“嘿，我看到你有关于所有用户的信息，给我那些 Name = John 的用户”，但它将由 DAL 负责实际上执行查询。您的控制器不是“声明” IQueryable，而是使用您的查询参数扩展 DAL 公开的 IQueryable 实体并要求 DAL 执行它。
那么听起来在这种情况下，如果我是正确的，通用存储库应该也可以工作？
当然可以。但是，请记住，通用存储库被许多人认为是一种反模式，因为它为每个实体定义了相同的行为，而业务逻辑通常需要某些实体的不同行为（例如，您可能希望提供删除特定实体的能力）逻辑上数据库中的实体 - 通过更改一些标志来告知记录是否仍然处于活动状态，并且对于其他实体，您希望删除是物理的）。在您的情况下，这可能不是问题，如果您是唯一的代码用户并且您的应用程序相对较小。