根据存储库模式，存储库应该提供查询还是实际实体？
我目前正在重构使用 ASP.NET MVC3、C# 和 Razor 开发的 Web 应用程序的代码。为了更好地构建我的应用程序，我使用的模式之一是 存储库模式，这除了是一种非常有用的模式之外，也是开发人员社区中经常讨论的问题。
在这种情况下，我找到了一篇文章 Fredrik Normen指出，根据Repository的定义，存储库类必须提供实际的实体（例如.NET中的List）而不是可查询的对象（.NET 中的 IQueriable）。而是在 ASP 的 NerdDinner 教程中.NET MVC 官方网站 当存储库必须提供同一对象的多个实例时，他们使用 IQueriable；当存储库必须提供对象的单个实例时，他们使用实际实体。
根据存储库模式对存储库类/接口进行建模时，最正确的方法是什么？
谢谢
弗朗西斯科
I am currently refactoring my code for a web application developed using ASP.NET MVC3 with C# and Razor. One of the pattern I am using in order to better structure my application is the Repository pattern, which, besides being a really useful pattern, is also a frequent matter of discussion within the developers' community.
In this context I found an article by Fredrik Normen which states that, according to the definition of Repository,a repository class must provide actual entities (for instance List in .NET) and not queriable objects (IQueriable in .NET). Instead in the NerdDinner tutorial from ASP.NET MVC official website they use IQueriable when the Repository has to provide multiple instances of the same object and the actual entity when the repository has to provide a single instance of the object.
What is the most correct approach to use when modeling a repository class/interface according to the Repository pattern?
Thanks
Francesco
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来这种事情不利于你的时间利用。 ;-)
理论上，您的存储库应该返回对象或其传统集合，是的。但是，即使您链接到的存储库模式的定义也使用术语“类集合接口”。当然，
IQueryable是一个“类似集合”的接口，是吗？在实践中，我几乎从不考虑其中的区别......但我总是尝试将所有查询代码放入存储库中。我想说，90% 的基于集合的存储库方法返回传统集合，而另外 10% 返回基于
IQueryable的内容。异常通常与分页有关；因此，如果需要的话，我可以从查询中获取总计，如果不需要，则不必提前获取该信息。这有点懒，但对我有用。但我确实认为总是尝试返回传统集合是一个好主意，因为这意味着您将所有查询封装在存储库中，这才是它应该在的位置。我建议不要太执着于坚持某人对 X 模式的要求的想法
In my opinion this sort of thing is detrimental to the use of your time. ;-)
In theory, your repository should return objects or traditional collections of them, yes. However, even the definition of the repository pattern you link to uses the term "collection-like interface". Certainly, an
IQueryable<Entity>is a 'collection-like' interface, yes?In practice, I almost never think about the distinction... but I always try to put all of the querying code in the repository. I'd say 90% of my collection-based repository methods return traditional collections, while the other 10% return something based on
IQueryable<>. The exceptions usually have to do with paging; so I can get the totals from the query down the line if needed, and not have to get that info early if I don't need it. It's a little lazy, but it works for me.But I do think it's a good idea to always try to return traditional collections, because that will mean you are encapsulating all of your querying in the repository, which is where it should be. I would recommend just not to get too caught up in the extreme levels of adhering to someone's idea of what the requirement is for pattern-X
正如您已经发现的那样，对此会有不同的意见。对于小型应用程序，让您的存储库公开 IQueryable 可能是可以的。
您当然不应该做的一件事是将 IQueryable 传递给您的视图。确保您的视图仅接收具体化对象和集合（例如列表或数组）。
这样，如果某个查询中存在错误，它将发生在控制器（或存储库）中，而不是在您的视图中。这使您能够测试查询并处理优雅的错误。
Opinions will differ on that, as you've already found. For small scale applications it's probably OK to let your repositories expose IQueryable.
One thing that you certainly should not do is pass IQueryable to your views. Make sure your views receive only materialized objects and collections (like List or arrays).
This way if an error exists in a query somewhere, it will occur in the controller (or repository) and not in your view. This enables you to test the queries and handle errors gracefully.