Stringa di connessione della riga di comando per l'aggiornamento del database di base EF
asp.net-core entity-framework-core
Domanda
Utilizzando ASP.NET Core e EF Core, sto cercando di applicare le migrazioni al database. Tuttavia, il login nella stringa di connessione in appsettings.json che l'app utilizzerà ha solo accesso CRUD, a causa di problemi di sicurezza, quindi non può creare tabelle e colonne, ecc. Quindi, quando corro:
dotnet ef database update -c MyDbContextName -e Development
Voglio dirgli di usare una stringa di connessione diversa, ma non so se questo può essere fatto? Fondamentalmente, voglio utilizzare due diverse stringhe di connessione, una per la distribuzione e una per l'esecuzione dell'app. È possibile? C'è un approccio migliore? Grazie.
Risposta accettata
Mantenere entrambe le stringhe di connessione in appsettings.json . Eredita una classe di contesto figlio da quella principale e sovrascrive OnConfiguring con un'altra stringa di connessione:
public class ScaffoldContext : MyDbContextName
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
string scaffoldConnStr = ConfigurationManager.ConnectionStrings["scaffoldConnStr"].ConnectionString;
optionsBuilder.UseSqlServer(scaffoldConnStr);
}
}
Quindi utilizzare:
dotnet ef database update -c ScaffoldContext
Risposta popolare
Mi piaceva l'idea di un DbContext di scaffold, ma ho trovato alcuni problemi (in qualche modo risolvibili, credo) e anche qualche considerazione su dove mantenere le stringhe di connessione. Quelli mi hanno portato a un'altra, più rozza soluzione, quindi ho pensato di condividere tutto questo qui.
Si tratta dell'approccio generale e della conseguente soluzione:
- Non mi piace memorizzare stringhe di connessione di gestione temporanea / di produzione sotto il controllo del codice sorgente. Quindi lo passerei attraverso una variabile di ambiente impostata in una finestra di comando temporanea (o forse al volo sulla riga di comando, anche se non ero in grado di farlo funzionare). A quel punto, se
MyDbContextNameuna variabile di ambiente, potrei anche sostituire la stringa di connessione iniziale utilizzata daMyDbContextName, invece di aggiungerne una nuova. In questo modo l'intera faccenda del DB di scaffolding potrebbe essere superata in questo modo.
Altri problemi che ho trovato lungo il percorso:
DbContext iniziale aveva le dipendenze iniettate nel costruttore, quindi il contesto figlio doveva fare lo stesso. Ciò ha reso i comandi
dotnet eflamentarsi della mancanza del costruttore senza parametri.Per superare questo, anche il contesto figlio è stato registrato all'avvio con
.AddDbContext<ChildDbContext>(...). Ciò è necessario anche per l'inserimento di ChildDbContext sia conDbContextOptions<ParentDbContext>che conDbContextOptions<ChildDbContext>. Successivamente,dotnet-efancora riscontrato problemi con l'istanziazione di ChildDbContext, in quanto era necessaria anche una dipendenza daIConfigurationche non è stata trovata. Forse (?) Questo è dovuto al fatto chedotnet-efnon viene eseguito attraverso l'intero avvio dell'applicazione.
Come ho detto, immagino che i problemi potrebbero essere risolti, ma sto ancora mettendo in discussione il reale valore di un contesto di scaffolding nel caso in cui non si voglia salvare le stringhe di connessione in file app dedicati. Un argomento del contatore potrebbe essere che si potrebbe dimenticare la variabile di ambiente impostata sulla stringa di connessione remota, ma è sufficiente chiudere la finestra di comando non appena si completa la migrazione. HTH
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow