存储库设计混乱

Question

我有以下存储库：

• EmployeeRepository
• DocumentRepository
• CourseRepository
• LeaveRepository

我们现在要求添加一个名为BusinessTripBidding的新业务对象，该对象允许员工竞标不同的商务旅行等。无论如何，问题是在返回Bidders列表时，我需要根据业务需要包含来自上述所有存储库的信息，然后我生成一个新对象并返回一个列表(在我的业务对象中)，如下所示：

IEnumerable<BidderInfo> GetBiddersInfo(int tripId)
{
List<Bidder> bidders = _bidderRepository.GetListByTripId(tripId);
List<Course> courses = _courseRepository
.GetListByEmployeeId(bidders.Select(b => b.EmployeeId).AsEnumerable());
List<Document> passports = _documentRepository
.GetListByEmployeeId(bidders.Select(b => b.EmployeeId).AsEnumerable(), DocumentType.Passport);
List<Leave> leaves = ...........
var biddersInfo = new List<BidderInfo>();
foreach(Bidder b in bidders)
{
var bi = new BidderInfo();
bi.Courses = courses.Where(c => c.EmployeeId == b.EmployeeId).ToList();
bi.Passport = passports.FirstOrDefault(p => p.EmployeeId == b.EmployeeId);
bi.ComingLeave = .........
// the same for the rest of the repositories
biddersInfo.Add(bi);
}
return biddersInfo;
}

除了对数据库的多次调用之外，在循环旁边，如果我创建一个新的存储库，只负责在单个查询中创建此BidderInfo，那么让我们调用它BidderInfoGeneratorRepository然后将此存储库注入业务对象的构造函数中。

现在，我应该保持目前的做法(多个数据库调用)但事情看起来正确; 还是应该创建另一个存储库并将其传递给业务对象以使事情更快一些？在这种情况下，最佳实践是什么？

Answer 1

最佳做法取决于数据的数量和更改速度。 如果您的数据只有几百/几千行并且变化缓慢，则可以将其缓存在应用程序中，并在更新时使缓存失效。 当您的数据太大而无法将其存储在内存中时，我会尽可能避免多次调用，而不会大幅增加代码复杂性。

Answer 2

我会避免存储库之间的紧密耦合。

虽然我是域优先、数据不可知论和其他实现基于 DDD 的架构的良好实践的忠实粉丝，但我想说的是，您仍然可以保留这些功能，而不需要以这种方式耦合您的存储库。

顺便说一句，如果我正确理解了你的方法，我发现你的推理中存在设计缺陷：BidderInfo是一个域对象，但它不是一个持久对象，不是吗？存储库旨在与数据映射层协同工作，以保留域更改并提供不可知的查询。

阅读您的代码，我的第一个结论是，整个方法应该进入域服务，您可以在其中注入任意数量的存储库，因为这是这样做的正确位置。

其次，有一些东西可以进一步简化事情，这可能是你的最终解决方案：为什么不把BidderInfo变成一个持久的对象呢？

如果我认为您使用的是 OR/M，我不应该猜错，对吧？因此，如果以正确的方式配置它，则可以保留BidderInfo并将其自动填充到单个查询中(或者谁知道呢，但它将是一个 OR/M 优化角色)。因此，您将创建整个BidderInfoRepository，只需在其上实现一个将在后台调用 OR/M 的GetById(...)。

否则，应将此代码放入服务层。