Como o projeto final funcionaria uma vez que o build do ScreenSound (console) falha uma vez que o ScreenSoundContext não tem o DbContextOptions?
Apenas deixei um construtor simples, sem parametros. O que eu quero saber é se faz sentido ter alguma injeção semelhante ao que ocorre no API, no program.cs.
Olá, Giovani. Tudo bem?
Essa é uma dúvida excelente e toca em um ponto crucial da evolução de um projeto: a transição de uma aplicação simples (Console) para uma arquitetura profissional com Injeção de Dependência (DI) e APIs.
O motivo do erro de build ocorre porque, ao usar o Entity Framework Core, o contexto precisa saber "como" se conectar ao banco (string de conexão, provedor, etc.). Na API, o ASP.NET Core faz isso automaticamente via Injeção de Dependência, mas no Console, você precisa configurar isso manualmente.
Sim, faz todo o sentido! Inclusive, em projetos modernos de grande porte, as aplicações Console (como Workers ou Jobs agendados) utilizam o mesmo motor de Injeção de Dependência que as APIs.
Existem três formas principais de resolver esse problema de compatibilidade:
Para que a API funcione e o Entity Framework consiga realizar as Migrations, o seu context deve ser assim:
public class ScreenSoundContext : DbContext
{
public ScreenSoundContext(DbContextOptions<ScreenSoundContext> options) : base(options)
{
}
}
Se você quer apenas que o Console volte a rodar rapidamente, você precisa instanciar as opções manualmente antes de criar o contexto:
var optionsBuilder = new DbContextOptionsBuilder<ScreenSoundContext>();
optionsBuilder.UseSqlServer("SuaStringDeConexaoAqui");
using var context = new ScreenSoundContext(optionsBuilder.Options);
Se você quer que o Console se comporte de forma semelhante à API, você pode instalar o pacote Microsoft.Extensions.Hosting e configurar um Host:
using var host = Host.CreateDefaultBuilder(args)
.ConfigureServices((context, services) =>
{
services.AddDbContext<ScreenSoundContext>(options =>
options.UseSqlServer("SuaStringDeConexao"));
})
.Build();
// Para usar o contexto:
var myContext = host.Services.GetRequiredService<ScreenSoundContext>();
Deixar o construtor simples (sem parâmetros) pode silenciar o erro de build, mas causará um erro em tempo de execução quando o EF tentar acessar o banco e descobrir que não tem as configurações necessárias. Além disso, a API não conseguirá injetar as configurações que você definiu no Program.cs.
Resumo: No mundo real, a gente raramente deixa o construtor vazio. Se o projeto é híbrido (Console + API), a melhor prática é garantir que ambos consigam passar o
DbContextOptionspara o contexto.
Você pretende manter as duas aplicações (Console e API) consumindo o mesmo banco de dados simultaneamente ou o Console foi apenas para a etapa inicial de aprendizado?