问题描述
我正在使用非常复杂的模型构建一个日历/条目/统计应用程序，其中包含大量模型之间的关系。
总的来说，我关心性能，正在考虑不同的策略，并在实施应用程序之前寻找输入。
我对 DBContextPooling 完全陌生，所以请原谅我可能提出的愚蠢问题。但是 DBContextPooling 与使用多个 DBContext 类有什么关系，还是不管使用单个或多个 DBContext 都与提高性能有关吗？
我最终可能会实现更多的 DBsets，还是应该避免它？为简单起见，我正在考虑创建多个 DBContext 类，但这会减少内存使用并提高性能吗？将应用程序拆分为更小的项目会更好/更智能吗？
使用 IEnumerable 和 ICollection 有什么性能差异吗？我尽可能避免使用列表。或者使用 IAsyncEnumerable 会更好吗？
解决方法
您的大部分性能痛点都来自您尚未简化的复杂架构。当一个用例受到另一个用例的影响并且您的关系如此交织时，管理一个单一的应用程序会导致许多不必要的“补偿”逻辑。
诸如是否使用上下文池或 IEnumerable vs ICollection 之类的优化可以稍后进行。它们不应影响您的解决方案的架构。
如果您的项目与您建议的一样复杂，那么我建议您阅读领域驱动设计和微服务并将您的应用程序分解为多个项目（或项目组）。
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/
每个项目（或项目组）都有自己的 DbContext 来管理该项目中的实体。 此外，每个 DbContext 应该从仅通过 DbSet 公开聚合根开始。这可能意味着比特定用例严格需要的更多的数据库活动，但最好从一个干净的架构开始，并在需要时挤压最后一点性能（有时以架构清晰度为代价）。
例如，如果您想将参加者添加到约会中，直接攻击参加者表可能很有吸引力。但是，为了保持干净，并且考虑到与会者没有预约就不能存在，那么您应该将预约设置为聚合根，并且仅将预约公开为外界攻击的入口点。该约会可以与其参加者一起从数据库中检索。然后要求约会添加与会者。然后通过在 DbContext 上调用 SaveChanges 来保存约会图。
总而言之，您的约会负责其图表中的功能。您应该要求约会将出席者添加到列表中，而不是将出席者添加到约会的出席者列表中。思维的微妙转变可以大大降低解决方案的复杂性。
艺术是决定微服务/上下文之间的边界应该在哪里。两种不同的架构可能有利有弊，没有明显的赢家
对于您的其他问题：
DbContext Pooling 是关于维护一个随时可用的实例化 DbContext 池。它节省了重复 DbContext 实例化的开销。可能不值得，除非您收到大量单独的请求，并且您的分析表明这是一个痛点。
所需的 DbSet 数量已在上文中提及。
至于 IEnumerable 或 ICollection 或 IList，这取决于您需要什么功能。这是一个很好的简单摘要... https://medium.com/developers-arena/ienumerable-vs-icollection-vs-ilist-vs-iqueryable-in-c-2101351453db
将应用程序拆分成更小的应用程序会更好/更智能吗？ 项目？
是的，绝对！从架构清晰度开始，然后在需要的地方和时间调整性能优势。不要以性能为目标（除非您正在构建一个毫秒敏感的解决方案）。