Inject AppDbContext with parameterized constructor
I'm trying to encapsulate the AppDbContext, so everything needed is passed in the constructor.
If I omit the "<IAppDbContext, AppDbContext>", it works for projects that have a reference to the Infrastructure, where AppDbContext resides. But if I want to use the IAppDbContext to inject it anywhere, it doesn't want to migrate.
The error:
"Unable to create an object of type 'AppDbContext'. "
20 Replies
when you say 'migrate', do you mean entity framework migrations or the construction of the DI service provider? where do you get the error specifically?
are your service classes actually asking for an
IAppDbContext
instead of a AppDbContext
in their constructors?
also, what happens if you just use .AddScoped<IAppDbContext>(_ => new ...
?dotnet ef migrations add initial_migration -s .\API\ -p .\Infrastructure\
same error
Yes, in my application layer I'm asking for IAppDbContext
ok, i'm not familiar with migrations so i don't think i'll be able to help - apologies
"Unable to create an object of type 'AppDbContext'. "sounds like somewhere you are asking for 'not the interface'
I checked it again, this is the only time I ask for it
For the migration, you can specify your dbcontext. I think it might need the real one thou, not the interface
I tried it, but same error unfortunately.
Hm, if you set up a unit test to verify your DI setup?
Does that pass?
Or use dbcontextoptions or whatever the normal way is to pass connection strings
Oh, that's probably it
I am able to use the db context the "normal" way by injecting with AddDbContext
but all of the configurations then take place outside of the AppDbContext class
I'm doing this for encapsulation
as taught by Vladimir Khorikov on Pluralsight
But he seems the be the only soul doing it that way
I certainly wouldnt be doing that string param injectin like that
I'm not really sure what you mean with encapsulation here. The custom context already encapsulates your db access
Encapsulating the context itself seems.. weird?
You think so? It kinda looks appealing to me to configure everything inside the AppDbContext class instead of in the Program.cs (or it's static extensions).
I removed the parameter and hardcoded the connection string in the AppDbContext constructor. Works now with
Question is now, how do I set the connection string properly?
IOptions pattern if there's not some property for it in the context options/builder.
Also, AddDbContext is more conventional than your registration above (which should just be
.AddScoped<IAppDbContext, AppDbContext>()
anyway)Oops, you are right. I don't need that provider => new stuff here anymore.
I'll try it with the IOptions then
That seems weird. You want the setup to be in program.cs with all the other configuration
The argument is that, if you have two options that need to be set in pairs, then they are encapsulated here
like if you have logging and then some logging option set, you would not want to set a logging option if logging is not set
This sounds like IDbContextOptions to me :p
Actually, yes. WTF am I doing?!
I'll use AddDbContext from now on. Thank you.