Unable to create DbContext
I'm trying to create by db tables right now, still in the start of a project.
I have a
ApplicationDbContext
in my Infrastructure project and I'm running dotnet ef migrations Initial
, that's all.
Project is public for now, could be seen here (yes, I know it's messy, I don't like clean architecture, I mostly don't know how to do it, not my style of coding)
Error Traceback:
28 Replies
Ah, btw, if you can't access the repo at any point, that's most likely I set it to private (I don't like unfinished public stuff), so just ask me and I'll set it to public again
your entrypoint application (.Api) doesnt register the DBContext
you've made an extension method for it in infra, but you never call it
that's bc I didn't reach that part yet d
well, the migration builder needs it
since it fake-starts the application to initialize the connection
you should also do
dotnet new gitignore
nobody wants to see obj
folders in gitI already have a gitignore
so you do. unfortunately, you didnt from the start
so you've already pushed the obj folders
so you'll need to remove them with
git rm
is it only that?
kinda seems weird
to fix the obj files, yes
I mean the dbcontext
I mean, look at the error message
Unable to resolve service for type 'Microsoft.EntityFrameworkCore.DbContextOptions1[Ilanos.Infrastructure.ApplicationDbContext]' while attempting to activate 'Ilanos.Infrastructure.ApplicationDbContext'
so its trying to resolve an ApplicationDbContext
, which is what we want
but it cant find the DbContextOptions<ApplicationDbContext>
registration in your DI container
thats because you never registered itI mean, that error means nothing to me, lol :d
also how do yall like clean architecture?
it kinda makes my code worse, lol
it sucks ass
$whynotca
CA is not necessarily difficult to understand conceptually, but they're difficult to build and difficult to maintain. When you build a real project, you will quickly (as often evidenced on this server) run into questions like "Is this an infrastructure object or a domain object?" or "Should I implement this contract in the infrastructure or the application?". Questions that a) take your time to ponder and ultimately answer, and b) distract you from doing your actual work.
It also adds unnecessary abstractions, by forcing you to use layers: both unnecessary layers and unnecessary decoupling between layers. For example, CA would generally argue that you should abstract the database into repositories and services should depend on an interface for the repository. However, modern ORMs like EFC already implement the repository pattern, by abstracting the implementation of a query via LINQ. Furthermore, in most applications, there's only one implementation of
IXxxRepository
- so why create the interface abstraction?
Instead, it's generally better to get rid of nearly all interfaces, keeping only ones that truly have more than one implementation; simplifying maintenance because any change to an api only needs to be done in one class instead of both class and interface. Smush all of the code down into a single Web project, or possibly two: Web and Services projects; removing any questions about "which project does this class go into?". Organize your code well in the Web project, with all of the User-related services/controllers/models/etc under /Features/Users/Xxx
; all of the Order-related services/controllers/models/etc under /Features/Orders/Xxx
; etc. Then it will be easy to find and maintain all of the code related to such and such feature. Any Infrastructure code (like emails, behaviors, startup code, etc.) can go under /Infrastructure/Xxx
, and any non-infrastructure code that's not related to a feature can go under /Features/Shared
.+1 to "it sucks ass" chorus
but wait, how do I do dotnet ef with those?
it still gives the same error even if I add it to the api proj
In Ilanos.Infrastructure
In *.Api
that second one
do I need to add the design one to the api too?
fix that
and yes, you should always be in the api project
but then doesn't it break the clean bs stuff
read up on
--target-project
and --startup-project
--target-project isn't a thing, is it just --project?
ah probably
erm, same thing here when using that
dotnet ef migrations add Initial --project src\Ilanos.Infrastructure\ --startup-project src\Ilanos.Api
ran this command
so I guess it just needs to have the design thingyit does indeed
uncle bob is angy now
As i see, you have not registered your infrastructure dependencies in program.cs
I have now, just not in git here
✅