我可以在存储库模型中使用它吗？

Question

我正在使用ASP.NET MVC和存储库模型开发项目。我有使用这些存储库类的存储库类和服务。我的问题是：从我的存储库类返回IQueryable然后在服务中使用“.Where”和“.OrderBy”来生成列表是否正确？如果是的话，这是最佳做法吗？

谢谢！

Answer 1

首先：这里没有“正确”或“错误”。这只是对您和您正在构建的系统最有效的问题。例如，Rob Conery做了一个名为Storefront的ASP.NET示例应用程序，其中包含您正在描述的模式，它点燃了一场大火焰战争。讨论的很大一部分是围绕Repository模式演变而来的，它被认为是Eric Evans在他的书Domain Driven Design中描述的“原始模式”，它描述了存储库的接口，它接受和/或返回实际实例（实例列表）而不是某些查询接口。

理论如此之多。您的系统选择什么？我不直接选择IQueryable路由的原因是它实际上将我的持久性策略泄漏到客户端层（在这种情况下是服务层）。因为如果使用LINQ to [数据库访问方法（如SQL，Entities，...）]从数据库中检索对象，则返回IQueryable主要是有意义的。只有这样才会。或者.Order可以优化您的查询结果。如果您正在使用某些数据库访问代码来获取完整列表，然后使用LINQ to Objects从存储库中公开，那么这显然没有意义。简而言之：您确实将客户端层绑定到您正在使用的基于LINQ的数据库访问策略中。

我自己有点纯粹主义者，我宁愿不从我的存储库中向LINQ表明这种关系，我会选择通过存储库操作的参数提供where-and-order-by标准。我可以在存储库中进行所有检索优化，并返回一组干净的域对象。

所以最后归结为：对你来说最好的一切都很好。

Answer 2

我不明白为什么会出现这个问题。如果您要在服务层中检索的数据中变得更具体，那意味着在应用程序和数据库之间传输的数据更少 - 这意味着更高的效率。这样做意味着您还将实现延迟加载，或在您绝对需要时获取数据。考虑到网络的无国籍状态，这是一件好事。如果可能使用它，您不希望检索所有数据。

换句话说，获取整个用户列表毫无意义，只需选择名称为“Jackolantern”的用户。

最好的方法就是这样 - 如果你决定明天从MSSQL切换到MySQL，你是否需要复制业务逻辑？如果是这样，那么你正在利用你的存储库不正确。

Answer 3

是的，我对返回IQueryable的存储库感到非常满意，但有一点需要注意：所有提供商都没有一些Linq功能。例如，Linq to Entities中没有Single / SingleOrDefault方法。因此，您的服务层可能必须跳过一些环节，具体取决于您使用的存储库的具体实现。

我通常将存储库类的接口放在域层中，将实际的实现放在服务层中。