我正在构建一个 MVC3 应用程序，尝试使用 IoC 和构造函数注入(inject)。我的数据库(到目前为止)大约有 50 个表。我正在为我的 DAC 代码使用 EF4(带 POCO T4 模板)。我正在使用存储库模式，每个表都有自己的存储库。我的服务层中的服务类被注入(inject)到这些存储库中。
问题:我的服务类需要的存储库数量正在增加。在某些情况下，我正在接近 10 个存储库，并且开始有异味。
是否有一种设计存储库和服务类的通用方法，使得服务不需要这么多存储库？
以下是我的想法，我只是不确定哪个是正确的:
1)这是一个迹象，我应该考虑将我的存储库组合/分组到表的相关部分，减少每个服务类的数量或依赖存储库。但是，这种方法的问题在于它会使我的存储库膨胀和复杂化，并且使我无法对所有存储库使用通用接口(interface)(数据检索/更新的标准方法)。
2)这是一个迹象，我应该考虑根据我的存储库(表)将我的服务分成组。问题是我的一些服务方法共享公共(public)实现，跨类打破这些可能会使我的依赖关系复杂化。
3)这是一个迹象，表明我不知道自己在做什么，并且有一些根本性的错误，我什至看不到。
更新:要了解我如何实现 EF4 和存储库，请查看 this sample app在 codeplex 上(我使用了 version 1 )。然而，看看那里(和这里)的一些评论，看起来我需要做更多的阅读以确保这是我想要采取的路线——听起来可能不是。
最佳答案
Chandermani is right您的某些表可能不是核心域类。这意味着您永远不会搜索该数据，除非根据单一类型的父实体。在这些情况下，您可以将它们称为“复杂类型”而不是成熟的实体，EF 仍会照顾您。
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)。旧版本也有，不过
DbContext通过将这些属性更改为 IDbSet，可以轻松调整模板以提供干净的可模拟实现。 .不过，我看过几篇教程文章，人们仍然在编写自己的文章。这对我来说很奇怪，因为他们通常不提供理由，除了他们正在“实现存储库模式”这一事实。
为这些存储库编写用于访问方法的包装器，例如
FindById使它更容易访问，但正如您所看到的那样，付出大量的努力可能带来的返回很少。就我个人而言，除非我发现有有趣的领域逻辑或复杂的查询需要封装，否则我什至不打扰，直接使用 Linq直接针对IDbSet .My service classes in my service layer are injected w/ these repositories.
即使您选择使用自定义查询包装器，您也可以选择简单地注入(inject)
DbContext ，并让服务代码实例化它需要的包装器。您仍然可以模拟您的数据访问层，只是无法模拟包装器代码。不过，我仍然建议您注入(inject)较少通用的，因为复杂的实现正是您希望能够在维护中排除或替换为模拟的类型。
关于asp.net-mvc - 为服务层设计 DI(构造函数注入(inject))存储库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8032852/