Proper usage of EF Core in teams?
hi all!
i dipped my toes into the world of .NET half a year ago (coming from the Java ecosystem). and so far, i like it quite much.
but one thing that keeps me struggling - EF Core. while i understand its power and benefits, it seems to be hard to use it in teams, especially when teams get larger and DB-involving features are implemented concurrently.
but how is EF Core supposed to be productively used within teams, while avoid a lot of additional work?
i dipped my toes into the world of .NET half a year ago (coming from the Java ecosystem). and so far, i like it quite much.
but one thing that keeps me struggling - EF Core. while i understand its power and benefits, it seems to be hard to use it in teams, especially when teams get larger and DB-involving features are implemented concurrently.
- the context model snapshot is something that always brings merge conflicts, and a little mistake when resolving them may cause a dangerous inconsistency
- the timestamps of the migrations can be a problem, especially if a "newer" feature is merged before an older one, and the timestamps are in wrong order then
- if you deploy stuff including DB changes to testing environments, e.g. new columns remain there, even if a different branch without those changes is deployed at a later point. that would require more maintenance because you'd have to configure CICD to do a rollback or something... you could also drop the db and recreate, but if you have environments that have some complex test data present, you would probably want to avoid such a nuke
but how is EF Core supposed to be productively used within teams, while avoid a lot of additional work?
