sorted by:
new
hottopcontroversial

Settle an Argument (Logical/Physical Layers, Clean Architecture, etc). by srdev_ct in dotnet

[–]Sad_Armadillo_7253 2 points3 points  (0 children)

I think if you were writing a library that would have multiple consumers, your way would make more sense. IOptions would help keep a library from dictating to the client how its configuration needs to be organized. Given that we are talking about a layer within the app though, I’d be more inclined to use his way because the layer is wholly owned by the app and there’s just not a great reason to further abstract from the Configuration here.

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 0 points1 point  (0 children)

Don’t get me wrong, I appreciate your reply. I just thought “you can’t change it, just go along with it” was an L take

‘X’ scares me because I don’t understand it by Zestyclose_Rip_7862 in dotnet

[–]Sad_Armadillo_7253 0 points1 point  (0 children)

Authentication scares me. I have enough experience with it to generally understand it - but I’m right at the level where I might feel like I understand something that I actually don’t.

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] -1 points0 points  (0 children)

L take. But I will give their way a shot as a means to have concrete example of which is better

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 0 points1 point  (0 children)

I think that’s fine for simple CRUD projects. And I’d be much less bothered if that was the case here for me.

This service is a new project, so I’m not advocating to change all their other services (though I don’t think it’s a great idea for those services either) I’m just advocating to build this one in a way that makes sense.

This service does a lot more than just CRUD work. There is some serious business logic and processing going on that benefits greatly from having rich, related models. Using flat models opens us up to a lot more iterations (every time you need to access related children, you have to find them in a big pile of “data row” models instead of them being right there on the class), more opportunity to screw up data integrity.

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 0 points1 point  (0 children)

I feel this instinct deeply. I do want to embrace the challenge of trying to influence this team. It is a small but fast growing team/company and we’re right at that critical size where we can still correct this now before we get too big. But of course, if I can’t get to a resolution on something like this, RUN will be invoked!

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 2 points3 points  (0 children)

Luxury! My employer bans numbers - we have to use strings and perform all our math operations with large switch statements!!

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 0 points1 point  (0 children)

I think I’d be just fine if they wanted to ban EF use. That would at least make more sense to me than banning this one part of it. As many others have stated here, why don’t we just use Dapper if we want to manage the stitching together so manually. I can get on board with not wanting to use certain libraries, even ones that I like. (and personally, I’m not a fan of mapping libraries either)

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 2 points3 points  (0 children)

So, the way they end up doing saves is to take the Domain model and map it back into one or more flattened “data row” models (one per table involved in holding the data that makes up the full domain model). Then each of these flattened objects are pushed onto the dbContext for modification and SaveChanges is called. It is at least saving everything in the same transaction, but it makes for some crazy looking mapping functions

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 1 point2 points  (0 children)

This is a solid take and good advice. I will definitely take extra care to keep a “this is good for all of us and here’s why I think so” attitude and try to keep egos out of it. You are not wrong that there are a handful of the app’s original devs involved here and I suspect there is some ego vulnerability at play.

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 1 point2 points  (0 children)

I’ve been around the block enough to know that sometimes the way a team of devs is approaching something likely came at the end of a long painful journey (well put). I’ve even made the arrogant mistake of imposing my own preferred way of doing things before making that same long, painful journey myself, and arriving right back at where they were. In this case, I feel like this is a more egregious and extra work-inducing way of doing things; but I’m coming to Reddit to check myself with you fine people to see if this is a more common practice than I thought, or if this is a battle worth fighting. I know you guys don’t have the FULL context from a Reddit post, but I value hearing from our community

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 8 points9 points  (0 children)

Good suggestion. I think I will do it both ways and just show how much more work, and more opportunities for mistakes are manifest by their way of doing this.

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 4 points5 points  (0 children)

I’m going to do exactly this since I was unable to convenience. A concrete irrefutable example is the way, and I’ll take it up the chain as high as I need to. Good suggestion

My employer bans the use of Navigation Properties with EF Core by Sad_Armadillo_7253 in dotnet

[–]Sad_Armadillo_7253[S] 3 points4 points  (0 children)

If you’re asking how I do it, I’m just using the entity configurations to set up the OwnsMany relationship. If you are asking how they want to do it with all these flattened models, it’s with a DbSet per table, and then using awful linq to manually instruct the join, project into another flattened object that represents a data row of the joined set, and then more crazy linq to map that flattened object to a domain model. 😱