asp.net-mvc - 我可以在存储库模型中使用它吗？

Question

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

谢谢！

Answer 1

对于初学者：这里没有“正确”或“错误”。这只是最适合您和您正在构建的系统的问题。例如，Rob Conery 使用您所描述的模式创建了一个名为 Storefront 的 ASP.NET 示例应用程序，它引发了一场激烈的战争。大部分讨论围绕存储库模式展开，该模式被认为是 Eric Evans 在他的《领域驱动设计》一书中所描述的“原始模式”，并将存储库的接口描述为接受和/或返回实际实例（实例列表），而不是一些查询界面。

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

作为一个纯粹主义者，我不希望从我的存储库中将这种与 LINQ 的联系浮出水面，我会选择通过存储库操作的参数提供 where 和 order-by 标准。我可以在存储库中进行所有检索优化，并返回一组干净整洁的域对象。

所以最后归结为：最适合你的就是好的。

Answer 2

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

换句话说，获取完整的用户列表，简单地选择名字是“Jackolantern”的用户是没有意义的。

最好的想法是这样的——如果你决定明天从 MSSQL 切换到 MySQL，你是否必须复制业务逻辑？ 如果是这样，那么您正在错误地使用您的存储库。

Answer 3

是的，我对返回 IQueryable 的存储库感到非常满意，但有一个警告：一些 Linq 函数并非在所有提供程序中都可用。例如，Single / SingleOrDefault 方法在 Linq to Entities 中不可用。因此，您的服务层可能不得不跳过一些环节，具体取决于您使用的存储库的具体实现。

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