Sto usando .Net core 2.1 + EF Core per creare WebApi. Sulla base di questa discussione: Entity Framework: un database, più DbContexts. È una cattiva idea? e il concetto di contesto limitato di DDD Voglio creare più DbContext per diverse funzionalità nella mia app. Esistono diverse risorse fornite da Julie Lerman su PluralSight.com ma non quelle che coprono le iniezioni di dipendenza nel .net core
. Finora ho fatto qualcosa del genere:
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));
qui DatabaseContext
è un contesto utilizzato per le migrazioni EF Core (in realtà non esegue query sui dati) e ProductContext
e CountryContext
sono due dei contesti che utilizzo per la mia manipolazione dei dati. Le mie domande sono:
AGGIORNAMENTO (2020-01-09)
Lo uso da più di un anno. Finora non si sono verificati problemi relativi alla connessione DB. Pianificazione di utilizzare questo approccio anche in progetti futuri.
Il concetto di avere contesti limitati va bene, di per sé. Si basa sull'idea che la particolare applicazione non dovrebbe avere accesso a cose di cui non ha bisogno. Personalmente, penso che sia un po 'eccessivo, ma le persone ragionevoli non sono d'accordo sulla questione.
Tuttavia, quello che hai qui è semplicemente sbagliato. Se la tua applicazione ha bisogno di accedere a tutti questi contesti limitati, non ha senso averli. Basta alimentarlo in un contesto con tutto l'accesso di cui ha bisogno. Sì, ogni contesto avrà una connessione separata, quindi sì, probabilmente avrai più connessioni nelle richieste di assistenza al gioco. Di nuovo, questo è il motivo per cui non ha senso dividere i tuoi contesti in questo scenario.
Se, tuttavia, dovessi adottare un approccio di architettura di microservizi, in cui ogni microservizio si occupava di un'unità discreta di funzionalità e volevi essere un purista, utilizzare contesti limitati avrebbe senso, ma in un'app monolitica non .