c# - 使用 Entity Framework 的存储库模式检索复杂对象图的模式

Question

我们有一个 ASP.NET MVC 站点，它使用带有存储库和 UnitOfWork 模式的 Entity Framework 抽象。我想知道其他人如何使用这些模式实现复杂对象图的导航。让我举一个我们的 Controller 的例子:

var model = new EligibilityViewModel
   {
       Country = person.Pathway.Country.Name,
       Pathway = person.Pathway.Name,
       Answers = person.Answers.ToList(),
       ScoreResult = new ScoreResult(person.Score.Value),
       DpaText = person.Pathway.Country.Legal.DPA.Description,
       DpaQuestions = person.Pathway.Country.Legal.DPA.Questions,
       Terms = person.Pathway.Country.Legal.Terms,
       HowHearAboutUsOptions = person.Pathway.Referrers
   };

这是一个注册过程，几乎所有内容都卡在 POCO 类 Person 上。在本例中，我们通过注册过程缓存此人。我现在已经开始实现注册过程的后半部分，这需要访问对象图中更深层的数据。具体来说，DPA 数据与国内法律无关。

上面的代码只是将模型信息映射为 ViewModel 的更简单的格式。我的问题是，您是否认为这种相当深入的图形导航是一种好的做法，或者您会将图形中进一步的对象检索抽象到存储库中吗？

Answer 1

在我看来，这里重要的问题是 - 您是否禁用了 LazyLoading？

如果您没有执行任何操作，则默认情况下它处于打开状态。

所以当你这样做时Person.Pathway.Country ，您将调用另一个对数据库服务器的调用(除非您正在进行急切加载，我稍后会谈到)。鉴于您正在使用存储库模式 - 这是一个很大的禁忌。 Controller 不应直接调用数据库服务器。

一旦C Controller 收到来自M模型的信息，它应该准备好进行投影(如果需要)，并传递到V 是的，不要返回到M模型。

这就是为什么在我们的实现中(我们还使用存储库、ef4 和工作单元)，我们禁用延迟加载，并允许通过我们的服务层(a一系列“包含”语句，通过枚举和扩展方法变得更加甜美)。

然后，我们立即加载这些属性，因为 Controller 需要它们。但重要的是， Controller 必须明确请求它们。

这基本上告诉用户界面 - “嘿，您只获得有关该实体的核心信息。如果您想要其他任何信息，请询问”。

我们还有一个服务层在 Controller 和存储库之间进行中介(我们的存储库返回 IQueryable<T> )。这允许存储库摆脱处理复杂关联的业务。预先加载是在服务层完成的(以及分页之类的事情)。

服务层的好处很简单——更松散的耦合。存储库仅处理添加、删除、查找(返回 IQueryable)，工作单元处理 DC 的“新建”以及更改的提交，服务层处理实体到具体集合的具体化。

这是一种很好的 1-1 堆栈式方法:

personService.FindSingle(1, "Addresses") // Controller calls service
 |
 --- Person FindSingle(int id, string[] includes) // Service Interface
      |
       --- return personRepository.Find().WithIncludes(includes).WithId(id); // Service calls Repository, adds on "filter" extension methods
           |
            --- IQueryable<T> Find() // Repository
                |
                 -- return db.Persons; // return's IQueryable of Persons (deferred exec)

我们还没有达到 MVC 层(我们正在做 TDD)，但是服务层可能是另一个可以将核心实体合并到 ViewModel 中的地方。再说一遍 - 由 Controller 决定它想要多少信息。

同样，这都是关于松散耦合的。您的 Controller 应该尽可能简单，而不必担心复杂的关联。

就有多少存储库而言，这是一个备受争议的话题。有些人喜欢每个实体都有一个(如果你问我的话就太过分了)，有些人喜欢根据功能进行分组(在功能方面有意义，更易于使用)，但是我们每个聚合根都有一个。

我只能在你的模型上猜测“Person”应该是我能看到的唯一聚合根。

因此，当路径始终与特定“人”相关联时，使用另一个存储库来处理“路径”没有多大意义。 Person 存储库应该处理这个问题。

再次强调 - 如果您对 EDMX 进行屏幕截图，我们可以为您提供更多提示。

根据问题的范围，这个答案可能有点过分了，但我想我会给出一个深入的答案，因为我们现在正在处理这个确切的场景。

HTH。