To cut a very long story short, ASP.NET Core with Entity Framework package provides a kind fo bridge between models represented as code/class and tables/fields in database. This way, we can do more by writing code, instead jumping between code and DB too often. However, you don’t need to use EF, if – for instance – you keep SQL queries as stored procedures on DB side. But, if you like to create tables by using C#, or other language, Entity Framework is the way to go.
Table/fields in database is representation of a model and its properties (class blueprint of model) on code side.
The whole transformation of class blueprint of a model into tables and fields on DB side is performed in 3 steps:
- create model class with properties, usually model name will table name, and properties will be fields names
- generate migration(s) – translate model class into set of instructions how to create tables/fields based on model properties, that is job of Entity Framework
- update DB based on instructions contained in the migrations – again Entity Framework helps
And, basically that is all. The advantage is, that we can edit migrations, and update a database if needed. It means, that if for some reason, in future, our model will need modifications, EF will help to modify migration (file with instruction for DB) which in turn will be used to updated tables/fields in database. So, we are concerned mainly on model’s and its properties, working mostly on code level, whereas Entity Framework does the job of translating it into instructions which database can understand.