.net core 2.1 несколько DbContext для одной базы данных - PullRequest
0 голосов
/ 11 сентября 2018

Я использую .Net core 2.1 + EF Core для создания WebApi. Основываясь на этом обсуждении: Entity Framework: одна база данных, несколько DbContexts. Это плохая идея? и концепция ограниченного контекста из DDD Я хочу создать несколько DbContext для различных функций в моем приложении. Джули Лерман предоставила несколько ресурсов на 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 отдельных соединения (и это будет расти), может ли это вызвать некоторые проблемы с доступом к данным в будущем, блокировки, конкуренцию и т. Д.?

1 Ответ

0 голосов
/ 11 сентября 2018

Концепция ограниченного контекста сама по себе прекрасна.Он основан на идее, что конкретное приложение не должно иметь доступа к тем вещам, которые ему не нужны.Лично я думаю, что это немного излишне, но разумные люди могут не согласиться по этому вопросу.

Однако то, что у вас здесь, просто неправильно.Если вашему приложению необходим доступ ко всем этим ограниченным контекстам, нет смысла их иметь.Просто предоставьте ему один контекст со всем необходимым доступом.Да, у каждого контекста будет отдельное соединение, так что да, вы, скорее всего, будете иметь несколько соединений в запросах обслуживания play.Опять же, именно поэтому нет смысла разделять ваши контексты в этом сценарии.

Если, однако, вы должны были использовать подход микросервисной архитектуры, в котором каждый микросервис имел дело с одной дискретной единицей функциональности, и вы хотели быть пуристом в этом, использование ограниченных контекстов имело бы смысл, но в монолитном приложении это не так.

...