存储库是否应该向服务提供所有数据？
我的意思是，假设我的存储库中有一个方法：
Public Function GetCustomerByState(ByVal State As String) As IQueryable(Of Customer)
服务是否能够以此扩展的形式获取附加数据，以获取客户的订单：
<Extension()> _
Public Function Include(Of T)(ByVal Source As IQueryable(Of T), ByVal Path As String) As IQueryable(Of T)
Dim ObjectQuery = CType(Source, ObjectQuery(Of T))
If (ObjectQuery IsNot Nothing) Then
Return ObjectQuery.Include(Path)
End If
Return Source
End Function
此扩展最有可能与通用方法一起使用存储库。
或者，您是否应该对每个聚合根的存储库进行具体实现，以准确返回服务所需的内容，而没有更多或更少？
那么，您的存储库是否应该返回 IQueryable？
What I mean by that is, say I have a method in my repository:
Public Function GetCustomerByState(ByVal State As String) As IQueryable(Of Customer)
Should the service be able to get additional data in the form of say this extension to say get the orders for the customer:
<Extension()> _
Public Function Include(Of T)(ByVal Source As IQueryable(Of T), ByVal Path As String) As IQueryable(Of T)
Dim ObjectQuery = CType(Source, ObjectQuery(Of T))
If (ObjectQuery IsNot Nothing) Then
Return ObjectQuery.Include(Path)
End If
Return Source
End Function
This extension is most likely used with a generic repository.
Or should you have concrete implementations of the repositories per aggregate root that return to the service exactly what it needs and nothing more or less?
Then, should your repositories even return IQueryable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我只会提供有限的方法集，例如：
原因是存储库用于提供对聚合根的数据访问的抽象，但业务逻辑负责定义应检索哪些数据。如果将太多逻辑传递到存储库中，您将在服务和存储库之间划分逻辑。此外，服务中的大多数数据检索方法不会执行任何操作 - 它们只会调用存储库方法。
Martin Fowler 清楚地说明了这一点：
在过去的几年里，Repository 和 UnitOfWork 模式在 .NET 世界中变得非常流行。但没有人谈论这个家族的第三种模式 - 规范。规范是传递到存储库的抽象查询，用于定义应返回哪些数据。 .NET 世界没有明确使用此模式，因为 IMO Linq-To-Entities 查询是规范。
I would offer only limited set of methods like:
The reason is that repository is used to provide abstraction of data access to agregation roots but the business logic is responsible for defining what data should be retrieved. If you pass too much logic into repository you will divide the logic between service and repository. Moreover most of your data retrieval methods in service will do nothing - they will just call repository method.
Martin Fowler says this clearly:
In past years Repository and UnitOfWork patterns became very popular in .NET world. But nobody speaks about third pattern from this family - Specification. Specification is an abtracted query passed to repository to define what data should be returned. .NET world doesn't use this pattern explicitly because IMO Linq-To-Entities queries are specifications.
我将从存储库中返回服务所需的所有内容。这是一个很好的做法，可以防止您编写重复的查询。我在 Repository with EF Code First 上写了一个答案，可能会有所帮助： Entity Framework 4 CTP 4 / CTP 5 通用存储库模式和可单元测试
请注意 - 存储库模式有许多不同的实现，并找到一个解决方案“感觉“正确”是我推荐的。在小型项目中，您可以返回 IQueryable，但如果它增长，您可能会后悔这个设计决策，因为很难保持事物干燥。
I would return everything the service needs from the Repository. It is good practice and will keep you from potentially writing duplicate queries. I wrote a SO answer on Repository with EF Code First that may help : Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable
Just a note - There are MANY different implementations of the Repository pattern and finding a solution that "feels" right is what I would recommend. In small projects you could return IQueryable but if it grows, you may regret the design decision as it becomes difficult to keep things DRY.