为服务层设计DI(构造函数注入)的存储库

Question

我正在构建一个MVC3应用程序,尝试使用IoC和构造函数注入.我的数据库(到目前为止)大约有50个表.我正在使用EF4(带有POCO T4模板)作为我的DAC代码.我正在使用存储库模式,每个表都有自己的存储库.我的服务层中的服务类是使用这些存储库注入的.

问题:我的服务类正在增加他们需要的存储库数量.在某些情况下,我正在接近10个存储库,它开始闻起来.

是否有一种设计存储库和服务类的通用方法,使得服务不需要这么多的存储库？

这是我的想法,我只是不确定哪一个是对的:

1)这是一个标志,我应该考虑将我的存储库组合/分组到表的相关部分,减少每个服务类的数量或依赖存储库.但是,这种方法的问题在于它会使我的存储库膨胀并使其复杂化,并使我无法使用所有存储库的通用接口(数据检索/更新的标准方法).

2)这是我应该考虑根据我的存储库(表)将我的服务分成组的标志.问题在于我的一些服务方法共享通用实现,并且跨类打破这些可能会使我的依赖项复杂化.

3)这表明我不知道自己在做什么,并且有一些我根本无法看到的根本错误.

更新:有关我如何实现EF4和存储库的想法,请在codeplex上查看此示例应用程序(我使用的是版本1).然而,看一下(和这里)的一些评论,看起来我需要做更多的阅读以确保这是我想要的路线 - 听起来可能不是.

Answer 1

如果您查看DDD聚合根模式并尝试在此透视图中查看数据,您会发现许多表根本没有独立存在.他们的数据仅在其父母的背景下有效.它们上的大多数操作都要求您获得父项.如果您可以对这些表进行分组并找到父实体\ repository,则可以删除所有其他子存储库.到目前为止你要在业务层进行的父子关联的复杂性(假设你使用独立的repo检索父和子)不会转移到DAL

重构服务接口也是一个可行的选择,并且任何常见的功能可以移动到基类中,\或者可以将自身定义为所有现有服务所使用的服务(Is A vs Has A)

Answer 2

Chandermani是正确的,你的一些表可能不是核心域类.这意味着除了单一类型的父实体之外,您永远不会搜索该数据.在这些情况下,您可以将它们称为"复杂类型"而不是完整的实体,EF仍然会照顾您.

我正在使用存储库模式,每个表都有自己的存储库

我希望你不要从头开始写这些.

EF 4.1已经实现了存储库模式(DbSet)和工作单元模式(DbContext).旧版本也是如此,尽管DbContext可以通过将这些属性更改为可以轻松调整模板以提供干净的可模拟实现IDbSet.

我看过几篇教程文章,人们仍然写自己的文章.这对我来说很奇怪,因为它们通常不提供理由,除了它们是"实现存储库模式"的事实.

为这些存储库编写包装器以获取访问方法,例如FindById使其更容易访问,但正如您所见,这是一项很大的努力,可能很少有回报.就个人而言,除非我发现有一些有趣的域逻辑或复杂的查询需要封装,否则我甚至都不会Linq直接使用它IDbSet.

我的服务层中的服务类是使用这些存储库注入的.

即使您选择使用自定义查询包装器,您也可以选择简单地注入DbContext,并让服务代码实例化它所需的包装器.您仍然可以模拟数据访问层,您将无法模拟包装器代码.我仍然建议你注入不那么通用的,因为复杂的实现正是你希望能够在维护中考虑因素或用模拟代替的东西.