✅ Question regarding EntityFramework
I have basically always made all of my models with Id's and then if it relates to another model, then include something like UserId.
I asked chatGPT to generate the skeleton for the DbContext and the models it had that stored UserId also had "public User user". I decided to check if this is a thing and apparently yeah it is. Does EFCore recognize the relation with that and how does it save it into a database? I am very confused and I can't find a proper example.
18 Replies
This is a complicated thing. I personally include User User and int UserId on my models. When you query an object, it will by default only query the id of the relationship and not the actual model unless you do (Include)
it had that stored UserId also had "public User user"It's not storing the ID, it's a navigation property It's what lets you do your
.Include()s, .Select()s and other nested queries
Without the need for manual .Join()s
In fact, relationships are set up based on those navigation properties
Not so much on IDsSomething that confuses new people is they don’t realize EF works by convention. If you have a property
public User User { get; set; } and another property public int UserId { get; set; } it will automatically set up the navigation and link the foreign key (UserId)
If you have complicated relationships or you don’t use normal naming conventions, you have to set up relationships with attributes/data annotations, or in OnModelCreating in your DbContextThat is pretty awesome then, I guess it would be useless in my case since I usually have authorization headers and I pull the ID's from claims. But what I am currently doing doesn't so I'll probably try using that, thanks!
EF has really good documentation. Give it a read
What do authorization headers have to do with how relationships are set up...?
I look at EF more as a lambda tool, I don't really know how deep it is. I have to read up on the docs
I usually set up my models exactly as they are on DB
Not sure what you mean by "lambda tool", but it's an ORM. It lets you create a database based on your C# code, and then query it as if it was a regular C# collection
Ah, oof, ouch, owie, my bones, they hurt
Database-first design
My condolences
What does this mean, doesn’t the model come before the data in the DB?
My sincere condolences
Hey, these are personal projects and I can press the nuke button whenever I want haha
Honest advice: use code-first design
Plus is you design the DB a bit better, no nukes need to be pressed, only mooore relations
Define your models, define your dbcontext, generate the database from that using migrations
This is the way
Sure. Thanks again for the extra advice too, I'll code the damn thing first and then connect it :D
Also check a look how that thing I asked works in practice
But the real reason for EF is that I don't have to waste half an hour on every small function making long SQL statements
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.This is resolved. I would like to thank @Playboi17 and @ZZZZZZZZZZZZZZZZZZZZZZZZZ again. I realized how this works and the in-built migration tool that previously murdered my development database can just pop a new one out of nowhere. Also the navigation thing makes the searches so much easier than before. Thank you!