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中的依赖项注入。到目前为止，我做了这样的事情：

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个独立的连接（并且此连接会不断增长），这会在将来引起一些数据访问问题，锁，并发性等吗？

Answer 1

具有有限上下文的概念本身很好。它基于这样的思想，即特定的应用程序不应访问不需要的东西。就我个人而言，我认为这有点过分，但是理性的人可以在这个问题上达成共识。

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

但是，如果您要采用一种微服务架构方法，其中每个微服务都处理一个离散的功能单元，和您希望对此持纯粹态度，那么使用有限上下文将是有意义的，但在整体应用程序中则不会。

Answer 2

只需针对每个上下文执行此操作：

        services.AddScoped<YourContext>(s =>
        {
            var builder = new 
            DbContextOptionsBuilder().UseSqlServer("ConnectionString");
            return new YourContext(builder.Options);
        });

.net core 2.1多个DbContext用于同一数据库

2 个答案: