Ho già messo il mio codice EF in una libreria di classi e lo uso in un progetto webapi asp.net. Tuttavia ho ancora il seguente codice nel mio progetto webapi.
services.AddDbContext<MyOwnDbContext>(
ops => ops.UseSqlite(connection, optionsBuilder => optionsBuilder.MigrationsAssembly("MyProject.API")));
C'è un modo per disaccoppiare completamente la classe 'MyOwnDbContext: DbContext' dal progetto webapi (usando una fabbrica o un'interfaccia). O questa è una preoccupazione non necessaria? Non voglio usare la libreria relativa a EF in due progetti.
Questa è una preoccupazione non necessaria. Lo metti nella radice della tua applicazione (Startup.cs). Tutto è cablato qui (contenitore di iniezione delle dipendenze, contesti, registrazione, ...).
In effetti non c'è posto migliore per dirlo. Perché la configurazione del contesto in sé non interessa per nessuno strato al di sotto del livello dell'applicazione. I tuoi DAL / repository utilizzano solo il contesto già configurato e il gioco è fatto.
Lo lascerei da solo, dal momento che è ancora necessario installare Entity Framework nel progetto di ingresso in modo che la libreria possa usarlo (o eseguire l'hacking attraverso la copia manuale dei file, ma non entriamo nel merito).
Tuttavia, questo è quello che ho fatto in un recente progetto in cui volevo mantenere tutti i miei servizi in un unico posto, diverso dalla classe Startup:
Microsoft.Extensions.DependencyInjection
nel progetto in cui desideri il tuo DbContext. Aggiungi qualcosa come questo:
public static class Injector
{
// you probably want to pass the connection string or an Options class here too
public static IServiceCollection Inject(this IServiceCollection services)
{
services.AddDbContext<...>(...);
return services;
}
}
Inietti, piuttosto che il contesto stesso:
public void Configure(IServiceCollection services)
{
services.Inject();
// and whatever else you need
services.AddMvc();
}
In questo modo, non vinci molto, ma potresti andare avanti come ho detto all'inizio.