2011-03-08 71 views
1

我的意思是,说我在我的仓库里的方法:存储库是否应该提供所有数据到服务?

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?

回答

2

我将只提供有限的一套类似的方法:

IQueryable<T> GetQuery(); 
T GetByKey(K key); 

的原因是仓库用于提供数据访问抽象agregation根,但商业逻辑是负责定义哪些数据被检索。如果你将太多的逻辑传递到存储库中,你会分开服务和存储库之间的逻辑。此外,大部分服务中的数据检索方法都无能为力 - 它们只会调用存储库方法。

Martin Fowler说,这清楚地:

阿库的 域和数据映射层间介导,作用 像一个内存域对象 集合。客户对象以声明方式构造 查询规范,并将 提交给Repository,以获得 满意度。

在过去的几年中,Repository和UnitOfWork模式在.NET世界变得非常流行。但是没有人会谈到这个家族的第三种模式 - Specification。规范是一个传递给存储库的抽象查询,用于定义应该返回的数据。因为IMO Linq-To-Entities查询是规范,因此.NET世界并未明确使用此模式。

+0

@Sam - 如果你想使用规范模式,这里是一个伟大的阅读http://huyrua.wordpress.com/2010/08/25/specification-pattern-in-entity-framework-4-revisited/ – Paul 2011-03-08 15:55:41

1

我会从Repository返回所有服务需求。这是很好的做法,并且可以避免潜在地编写重复查询。我在EF Code First上写了一个关于Repository的SO解答,可能有所帮助:Entity Framework 4 CTP 4/CTP 5 Generic Repository Pattern and Unit Testable

只是一个说明 - 有很多不同的Repository模式实现,找到一个“感觉”正确的解决方案就是我会推荐的。在小型项目中,您可以返回IQueryable,但如果它增长,您可能会后悔设计决策,因为难以保持干爽。