Scaffold tool: add a flag to generate the constructor with DbContextOptions injected

[ryanelian]

Currently, scaffold existing database tool will generate an OnConfiguring method with connection string inside:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    #warning To protect potentially sensitive information in your connection string, you should move it out of source code. See http://go.microsoft.com/fwlink/?LinkId=723263 for guidance on storing connection strings.
    optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;");
}

I realized this result is by-design to make the the result of reverse engineering to be runnable (#10432), however, shouldn't there be an flag for people who needs an injected DbContextOptions instead?

--inject-dbcontextoptions

public BloggingContext(DbContextOptions<BloggingContext> options)
    : base(options)
{ }

With this flag, we can re-scaffold the context from existing database without touching the constructor again.

I mean, people who use EF Core in ASP.NET Core MVC app will tend to add the DB context into the service collection using AddDbContextPool...

[ajcvickers]

Discussed in triage and adding to the backlog. It seems like it may be fine to generate both constructors. For now, the constructor can be added to a partial class.

[Jrubzjeknf]

For anyone wondering how to use this functionality: you must specify your connectionstring to be named, which looks like name=MyConnectionString. The name of your connection string corresponds with the one defined in your appsettings.json.