asp.net-mvc – 为服务层设计DI(构造函数注入)的存储库

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

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

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

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

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

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

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

更新：有关我如何实现EF4和存储库的想法,请查看codeplex上的this sample app(我使用过version 1).然而,看一下(和这里)的一些评论,看起来我需要做更多的阅读以确保这是我想要的路线 – 听起来可能不是.

解决方法

I am using the repository pattern,and each table has its own repository

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

EF 4.1已经实现了the Repository Pattern(DbSet)和the Unit of Work pattern(DbContext).旧版本也可以,但可以通过将这些属性更改为IDbSet,轻松调整DbContext模板以提供干净的可模拟实现.

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

为FindById这样的访问方法编写这些存储库的包装器使得访问稍微容易一些,但正如您所看到的那样,大量的工作可能很少有回报.就个人而言,除非我发现有一些有趣的域逻辑或复杂的查询需要封装,否则我甚至不会费心直接使用Linq来对抗IDbSet.

My service classes in my service layer are injected w/ these repositories.

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

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!