使用 Linq2Nibernate 和 IQueryable 进行界面设计答案

【问题标题】：interface design with Linq2Nibernate and IQueryable使用 Linq2Nibernate 和 IQueryable 进行界面设计
【发布时间】：2010-10-13 00:27:58
【问题描述】：

当使用 Linq2Nibernate 时最好让你的 Repository 返回一个 IQueryable？

我的理解是，如果您使用 Linq 来 Nibernate，则在您调用 .First() 或 Single() 等之前，查询不会“触发”。那么最好从所有接口返回 IQueryable 以便您可以在触发之前构建\操作表达式树吗？

我的存储库由服务调用并从 IServicie 继承。

编辑：

首先，我真的很感谢所有的答案。但我想对这个问题补充一点。我赞成这个设计。我不完全理解围绕测试的保留意见。只要在每个过滤点（即每个过滤点）都测试该过程，那么我真的看不出有太大的区别。

补充：

如果您的存储库不返回 IQuerrable，那么使用 Linq2Nibernate 有什么意义吗？

【问题讨论】：

标签： c# .net linq iqueryable linq-to-nhibernate

【解决方案1】：

我个人认为不会。从存储库中公开可组合查询的问题在于，您不能再对它们进行完全单元测试——它们的行为（和成功）现在由调用者摆布。例如，他们可能会做.Where(x=>SomeUnmappedMethod(x))（没有翻译）。我在here 上添加了更多内容。

如果您有返回（例如）IList<T> 或T[] 的固定方法，那么您可以确定如果它在单元测试中有效，它应该可以真正有效（除非有任何配置错误）。这也意味着您可以单独分析 DAL，并对将要执行的 SQL（等）有合理的信心。您无法分析/优化根据调用者更改的 DAL。

（基于我的 LINQ-to-SQL 用法；不是专门针对 LINQ-to-NHibernate）

【讨论】：

关于隔离，你不会仍然暴露给调用者访问你没有加载的关系吗？
我明白你的意思真的很感谢你的意见，但这不是真正充分利用了Linq2Nibernate吗？如果您不能应用“管道和过滤器”类型模式 PRE 数据库提取，我真的看不出使用它有什么好处
@Ted 你使用规范模式，它可以以非常相似的方式工作......基本上你将这些过滤器传递给方法（而不是在调用方法后应用它们）
@Marc 您可能想澄清这些是集成测试，请参阅乍得的编辑和我对此的评论
您可以使用完整的 LINQ 内容inside 存储库...或使用 IQueryable - 由您决定...

【解决方案2】：

这取决于消耗您的“存储库”的内容（由于含糊不清而引用）。我会说，如果像您的最后一层 (UI) 之类的东西正在使用您的存储库类以 NOT 返回 IQueryable。但是，如果您的 UI 层和数据访问层之间有另一层，我会说是，返回 IQueryable 并让您的中间层处理查询的执行。

编辑

至于测试您的数据访问层 (DAL)/存储库，我会说大部分情况，除非您有实际的逻辑（if 语句等），否则应该几乎没有测试。此时，您正在测试框架。我的建议是在您的访问层 (UI) 和 DAL 之间放置另一层，例如 BLL 或处理 IQueryable 查询执行的东西。这样，您的存储库可以返回查询，而您的 BLL 可以处理执行它们，并可能执行一些可以测试的逻辑。

【讨论】：

在这种情况下，它不是在测试框架，而是在进行集成测试——确保它与当前版本的数据库一起工作，即有人没有机会破坏它……我很担心马克称之为“单元”测试，这是错误的看法

【解决方案3】：

我不使用 IQueryable，但我会解释为什么我做的有点不同：

更容易模拟存储库，测试使用它的其他代码
集成测试 - 导致查询被触发的大部分内容都在存储库中，因此我可以针对它进行一些真正集中的集成测试
与第一个相关，更容易检查代码是否对存储库进行了适当的调用。这是因为调用代码会将过滤器信息传递给存储库方法调用，而不是将它们应用于结果。

【讨论】：