entity-framework - .net core 2.1同一数据库的多个DbContext

Question

我正在使用.Net core 2.1 + EF Core来构建WebApi。基于此讨论:Entity Framework: One Database, Multiple DbContexts. Is this a bad idea?以及 DDD 中的有界上下文概念，我想为我的应用程序中的不同功能创建多个 DbContext。 Julie Lerman 在 PluralSight.com 上提供了多种资源，但其中没有涵盖 .net core 中的依赖项注入(inject)。到目前为止我做了这样的事情:

var connectionString = Configuration.GetConnectionString("DatabaseName");
 
services.AddDbContext<DatabaseContext>(options =>
    options.UseSqlServer(connectionString, optionsBuilder =>
        optionsBuilder.MigrationsAssembly("Database.Migrations")));
services.AddDbContext<ProductContext>(options =>
    options.UseSqlServer(connectionString));
services.AddDbContext<CountryContext>(options =>
    options.UseSqlServer(connectionString));

这里的DatabaseContext是用于EF Core迁移的上下文(实际上并不查询数据)，ProductContext和CountryContext是其中的两个我用于数据操作的上下文。我的问题是:

• 这是正确的做法吗？重复使用相同的连接字符串感觉有点奇怪
• 感觉我会使用 2 个独立的连接(而且这个连接还会增长)，这是否会导致将来出现一些数据访问问题、锁定、并发等问题？

更新 (2022-11-11)

我已经使用这个好几年了。到目前为止没有任何与数据库连接相关的问题。计划在未来的项目中也使用这种方法。

Answer 1

有界上下文的概念本身就很好。它基于这样的想法:特定应用程序不应该访问它不需要的东西。就我个人而言，我认为这有点矫枉过正，但理性的人可能会在这个问题上存在不同意见。

但是，您在这里所看到的完全是错误的。如果您的应用程序需要访问所有这些有界上下文，那么拥有它们就没有意义。只需为其提供一个上下文及其所需的所有访问权限即可。是的，每个上下文都会有一个单独的连接，因此，是的，您可能在播放服务请求中拥有多个连接。同样，这就是为什么在这种情况下划分上下文是没有意义的。

但是，如果您要采用微服务架构方法，其中每个微服务处理一个离散的功能单元，并且您希望成为它的纯粹主义者，那么使用有界上下文是有意义的，但在单体应用程序中则不然。