Entity Framework Core and the Code-First Way of Managing a Database
I manage the database schema through code instead of writing raw SQL by hand.
Mert Celal Yılmaz · Full Stack Developer · Updated:
Changing a database schema doesn't have to mean opening a database tool and editing tables by hand, it can just as easily happen through code. Entity Framework Core is the ORM for .NET that makes that possible: you define your classes as entities, and EF Core maps them to tables. You write queries in LINQ, and they get translated into SQL Server queries behind the scenes. With a code-first approach, the schema moves forward through migrations instead, versioned right alongside the code and trackable in the git history.
I've used EF Core as the ORM layer on top of SQL Server in an apartment management system and in a corporate business management platform. Adding a field to an entity, changing a relationship, or adding an index all go through the same routine: generate a migration, review it, apply it. It's not a separate database-admin task, it's just part of finishing a feature before committing it.
Looking back through the migration history actually shows you how the database side of a project evolved over time. Which table got which column and when, which relationship changed and why, it's all sitting right there in the folder. Having the schema tracked alongside the code makes refactoring noticeably less nerve-wracking.
DbContext's change tracking works off a snapshot: when an entity gets loaded, EF Core keeps a copy of its original values in memory, and at SaveChanges time it diffs that snapshot against the current state to build UPDATE statements touching only the columns that actually changed. On a table like assessment records in the apartment management system, which gets touched constantly, that means writes stay narrow instead of rewriting the whole row every time.
Letting migrations auto-generate has a trap that's easy to miss: EF Core has no idea a column got renamed, it just sees one column disappear and another appear, and treats it as drop-then-add, which silently deletes data if applied as-is. I've learned to open the generated migration file before running it against anything real, especially when a rename or type change is involved. On the corporate management platform, with tables that already carry real records, I run that kind of migration against staging first rather than trusting the generated script blindly.