If you really want to create the context manually, then you can configure it like this:
var optionsBuilder = new DbContextOptionsBuilder<ApplicationDbContext>();
optionsBuilder.UseSqlServer(Configuration.GetConnectionStringSecureValue("DefaultConnection"));
_context = new ApplicationDbContext(optionsBuilder.Options);
(The DbContextOptionsBuilder<ApplicationDbContext>
class is the type of options
argument in services.AddDbContext<ApplicationDbContext>(options =>
).
But in the controller, you don’t have access to Configuration
object, so you would have to expose it as a static field in Startup.cs
or use some other trick, which is all bad practice.
The best way to obtain ApplicationDbContext
is to get it through DI:
public GigsController(ApplicationDbContext context)
{
_context = context;
}
The DI container will take care of instantiating and disposing of ApplicationDbContext
. Note that you have everything correctly configured in Startup.cs
:
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
That’s configuring DI, so why not just use it?
One more note about the default constructor of DbContext
: In EF6 it was done like this: public ApplicationDbContext(): base("DefaultConnection") {}
. Then the base object would use System.Configuration.ConfigurationManager
static class to obtain the connection string named DefaultConnection
from web.config
. The new Asp.net Core and EF Core is designed to be as much decoupled as possible, so it should not take dependencies on any configuration system. Instead, you just pass a DbContextOptions
object – creating that object and configuring it is a separate concern.