Code First and Database First

There are two directions you can work in. Code first means your C# classes are the source of truth and migrations push their shape into the database. Database first means the database is the source of truth and your classes are generated from it.

These are often presented as a preference, as though one were modern and the other dated. They are not. The question that decides it is who owns the schema — whose approval is needed to add a column, and what the rest of the organisation expects when the shape of the data changes.

Answer that first, and the technical choice follows without much argument.

# Reverse-engineer every table into entity classes plus a DbContext
dotnet ef dbcontext scaffold "Name=ConnectionStrings:AnviDatabase" Microsoft.EntityFrameworkCore.SqlServer --output-dir Models --context-dir Data --context AnviContext --no-onconfiguring

# Limit it to the tables you need
dotnet ef dbcontext scaffold "Name=ConnectionStrings:AnviDatabase" Microsoft.EntityFrameworkCore.SqlServer --table Employees --table Departments --output-dir Models

# After a schema change, regenerate -- overwriting what is there
dotnet ef dbcontext scaffold "Name=ConnectionStrings:AnviDatabase" Microsoft.EntityFrameworkCore.SqlServer --output-dir Models --force

• Name=ConnectionStrings:AnviDatabase reads the connection string from configuration rather than putting credentials on your command line and into your shell history.
• The provider is named as the second argument, because reverse engineering has to understand the source database's own types.
• --no-onconfiguring keeps the connection string out of the generated context, so the application can supply it the normal way through AddDbContext.
• --table restricts the output. A database with four hundred tables does not need four hundred entity classes in your project, and scaffolding only what you query keeps the model smaller and faster to build.
• --force overwrites the previously generated files. Read that again before using it: anything you edited by hand in those files is gone.

// Models/Employee.cs -- generated. Do not edit; it will be overwritten.
public partial class Employee
{
    public int Id { get; set; }
    public string Name { get; set; } = null!;
    public int DepartmentId { get; set; }
    public decimal AnnualSalary { get; set; }

    public virtual Department Department { get; set; } = null!;
    public virtual ICollection<Order> Orders { get; set; } = new List<Order>();
}

// Models/Employee.Extensions.cs -- yours. Survives regeneration.
public partial class Employee
{
    public string DisplayName => Name + " (" + DepartmentId + ")";
}

• Generated entities are partial classes, which is the escape hatch that makes database first workable. Your additions go in a second file with the same class name, and regenerating the first one leaves it alone.
• Column names become property names directly. A legacy table with a column called EMP_SAL_ANN produces a property called EMP_SAL_ANN, which is honest about the database and unpleasant to read. You can rename with configuration, but the generated file will not do it for you.
• The generated classes reflect tables, not your domain. A table with forty nullable columns becomes a class with forty nullable properties. Many teams treat these as a data access layer and map them into their own types.
• There is no migration history in this approach, so the database is not created from your code. A new developer needs a database restored or built by whoever owns it.