为服务层设计DI（构造函数注入）的存储库 [英] Designing repositories for DI (constructor injection) for service layer

问题描述

我正在构建一个MVC3应用程序，试图使用IoC和构造器注入。我的数据库（到目前为止）有大约50个表。我正在使用EF4（w / POCO T4模板）作为我的DAC代码。我正在使用存储库模式，每个表都有自己的存储库。我的服务层在我的服务层被注入这些存储库。

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

是否有一种常用的方法来设计存储库和服务类，以便服务不需要这么多知识库？

这是我的想法，我只是不知道哪一个是正确的：

1）这是一个符号，我应该考虑将我的存储库组合/分组到表的相关部分，减少每个服务类的数量或相关的存储库。这种方法的问题是，它会使我的存储库膨胀和复杂化，并且将使我无法使用所有存储库的通用接口（用于数据检索/更新的标准方法）。

2）这是一个标志，我应该考虑根据我的存储库（表）将我的服务分组。这样做的一个问题是，我的一些服务方法有共同的实现方式，而且跨越类可能会使我的依赖性复杂化。

3）这是一个迹象，知道我正在做什么，并有一些根本错误的东西，我甚至不能看到。

更新：我如何实施EF4和存储库，请查看codeplex上的此示例应用程序（我使用版本1 ）。然而，看看那里的一些评论（和这里），看起来像我需要做更多的阅读，以确保这是我想要的路线 - 听起来可能不是。

$ b

服务层/ 8033021＃8033021> Chandermani是对的，你的一些表可能不是核心域类。这意味着除了单一类型的父实体外，您将永远不会搜索该数据。在这些情况下，您可以将它们称为复杂类型而不是完整的实体，而EF仍然会照顾您。

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

我希望你不要从头开始写这些。 / p>

EF 4.1已经实现了存储库模式（ DbSet ）和工作单位模式（ DbContext ）。旧版本也是这样，虽然 DbContext 模板可以很容易地被调整，以便通过将这些属性更改为 IDbSet 。

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

为这些存储库编写包装器对于诸如 FindById 的访问方法，使其访问更容易一些，但正如您所看到的那样，大量的努力可能很少有回报。就个人而言，除非我发现有一些有趣的领域逻辑或复杂的查询被封装，我甚至不打扰，只需使用 Linq 直接针对 IDBSet 。

我的服务层中的服务类在这些存储库中注入。 b $ b

即使您选择使用自定义查询包装器，也可以选择简单地注入 DbContext 并让服务代码实例化它所需的包装器。您仍然可以嘲笑您的数据访问层，您将无法模拟包装代码。尽管如此，我仍然建议您注入较少的通用程序，因为复杂的实现正是您希望能够在维护中进行考虑或者用mocks替代的类型。

I'm building an MVC3 app, trying to use IoC and constructor injection. My database has (so far) about 50 tables. I am using EF4 (w/ POCO T4 template) for my DAC code. I am using the repository pattern, and each table has its own repository. My service classes in my service layer are injected w/ these repositories.

Problem: My service classes are growing in the number of repositories they need. In some cases, I am approaching 10 repositories, and it's starting to smell.

Is there a common approach for designing repositories and service classes such that the services don't require so many repositories?

Here are my thoughts, I'm just not sure which one is right:

1) This is a sign I should consider combining/grouping my repositories into related sections of tables, reducing the number or dependent repositories per service class. The problem with this approach, though, is that it will bloat and complicate my repositories, and will keep me from being able to use a common interface for all repositories (standard methods for data retrieval/update).

2) This is a sign I should consider breaking my services into groups based on my repositories (tables). Problem with this is that some of my service methods share common implementation, and breaking these across classes may complicate my dependencies.

3) This is a sign that I don't know what I'm doing, and have something fundamentally wrong that I'm not even able to see.

UPDATE: For an idea of how I'm implementing EF4 and repositories, check out this sample app on codeplex (I used version 1). However, looking at some of the comments there (and here), looks like I need to do a bit more reading to make sure this is the route I want to take -- sounds like it may not be.

解决方案

Chandermani is right that some of your tables might not be core domain classes. This means you would never search for that data except in terms of a single type of parent entity. In those cases you can reference them as "complex types" rather than full-blown entities, and EF will still take care of you.

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

I hope you're not writing these yourself from scratch.

The EF 4.1 already implements the Repository Pattern (DbSet), and the Unit of Work pattern (DbContext). The older versions do too, though the DbContext template can easily be tweaked to provide a clean mockable implementation by changing those properties to an IDbSet.

I've seen several tutorial articles where people still write their own, though. It is strange to me, because they usually don't provide a justification, other than the fact that they are "implementing the Repository Pattern".

Writing wrappers for these repositories for access methods like FindById make it slightly easier to access, but as you've seen is a big amount of effort potentially little payback. Personally, unless I find that there is interesting domain logic or complex queries to be encapsulated, I don't even bother and just use Linq directly against the IDbSet.

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

Even if you choose to use custom query wrappers, you might choose to simply inject the DbContext, and let the service code instantiate the wrappers it needs. You'd still be able to mock your data access layer, you just wouldn't be able to mock up the wrapper code. I'd still recommend you inject less generic ones though, because complex implementation is exactly the type of thing you'd like to be able to factor out in maintenance, or replace with mocks.

这篇关于为服务层设计DI（构造函数注入）的存储库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！