根据Repository模式，存储库应该提供查询还是实际实体？

Question

我目前正在为使用带有C＃和Razor的ASP.NET MVC3开发的Web应用程序重构我的代码。我为了更好地构建我的应用程序而使用的模式之一是Repository pattern，除了是一个非常有用的模式之外，它也是开发人员社区中经常讨论的问题。

在这个上下文中，我发现Fredrik Normen的一篇文章指出，根据Repository的定义，一个存储库类必须提供实际的实体（例如.NET中的List）而不是可查询的对象（IQueriable in。净）。而在ASP.NET MVC官方网站的NerdDinner tutorial中，当存储库必须提供同一对象的多个实例时，以及当存储库必须提供对象的单个实例时，它们使用IQueriable。

根据存储库模式对存储库类/接口进行建模时，最正确的方法是什么？

由于

弗朗西斯

Answer 1

在我看来这种事情对你的时间利用是有害的。 ; - ）

理论上，您的存储库应该返回对象或它们的传统集合，是的。但是，即使您链接到的存储库模式的定义也使用术语“类似集合的接口”。当然，IQueryable<Entity>是一个“类似集合”的界面，是吗？

在实践中，我几乎从不考虑这种区别......但我总是试图将所有查询代码放在存储库中。我会说90％的基于集合的存储库方法返回传统集合，而其他10％返回基于IQueryable<>的东西。例外通常与分页有关;因此，我可以从查询中获取总计，如果需要，如果我不需要它，则不必提前获取该信息。这有点懒，但对我有用。

但我认为总是尝试来返回传统集合是一个好主意，因为这意味着你将所有查询都封装在存储库中，这应该是它应该存在的地方。我建议不要太过追随某个人对于模式X的要求是什么的极端程度

Answer 2

正如您已经发现的那样，意见会有所不同。对于小规模应用程序，可能会让您的存储库暴露出IQueryable。

你当然不应该做的一件事是将IQueryable传递给你的观点。确保您的视图只接收物化对象和集合（如List或数组）。 这样，如果某个查询中存在错误，它将出现在控制器（或存储库）中，而不是在您的视图中。这使您可以正常测试查询和处理错误。