我是一个由4人组成的团队的成员，负责管理一个大型旧应用程序，该应用程序最近已转换为.Net Core。
此刻，我们的数据访问是用一个自制的准ORM完成的，这很糟糕。我们想迁移到EF Core，先编码。
我们的数据库有大约200个表。该架构已在超过15年的时间里临时增长，因此没有真正的“架构”。
我们中有些人希望将所有表定义放入一个DbContext中，以使维护简单。其他人则希望将表拆分为多个DbContext，因为在他们看来，具有很多表的单个DbContext会给我们带来不好的性能。
对我们而言，可维护性是一个真正的问题，因为1）对于我们的客户而言，引入错误会很快导致很多痛苦； 2）我们需要能够与一个小型团队一起快速构建新功能，以保持竞争优势。另一方面，严重的性能下降是不可接受的。
将所有200个表粘贴在一个DbContext中会更好，还是将它们拆分为多个DbContext会更好？
答案 0 :(得分：0)
有界上下文将减少数据库上下文的“加速”时间。 200个表不一定是考虑它们的原因，它将更多地取决于表之间映射的关系数。围绕大型上下文的性能问题通常与上下文跟踪的数据多于所需的数据和生存时间超过所需的时间有关，但是大型，复杂的模型结构可能会增加请求的时间。
在考虑有限的上下文结构时，您将需要选择区域以确保可以由单个上下文满足请求。避免需要旋转多个上下文来满足请求的情况，或者可以在上下文之间共享实体的情况。如果您的代码采用通用存储库之类的模式，这可能会很棘手。如果现有代码使用的是通用存储库，则通常最好使用单个DbContext，因为这些存储库将要与单个DbContext进行通信，而最终由于控制器/服务代码无意中产生了多个上下文而变得很容易，或者传递带有不同DbContext跟踪（或不跟踪）的引用的实体引用。
当使用有界上下文时，我基本上使用一组有界的存储库，这些存储库具有更“垂直”的配置文件，其中特定的控制器将拥有自己的存储库，该存储库为该控制器的主要实体和支持实体提供服务。一个或多个控制器/存储库将由有界的DbContext提供服务。