What should be the entity model of the application?

Question

ASP.NET

Hello! I understand the architecture of the application and the question arose of what the application entity model should be, meaning which entities to use to write data to the database, this model should be a complete copy of the database structure, for example, such a model that the Entity Framework generates

public class Player
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Position { get; set; }
    public int Age { get; set; }
 
    public int? TeamId { get; set; }
    public virtual Team Team { get; set; }
}
public class Team
{
    public int Id { get; set; }
    public string Name { get; set; } // название команды
    public string Coach { get; set; } // тренер
 
    public virtual ICollection<Player> Players { get; set; }
 
    public Team()
    {
        Players = new List<Player>();
    }
}

or should it be a model similar to a business object, for example, I have an order business object that does not use all the fields from the table

public class Team
{
 public int Id {get;set;}
 public int Price{get;set;}
}

and the table still has fields for example CreatedDate, well, etc., so the question would be more correct to make a model that copies the database including links, or to make a model of the type of Business objects? I just understand this, so tell me how it will be more correct, criticism, advice, links to useful literature, everything is accepted

Answer 1

Entity (entity) should represent our table in the database, and ideologically should include all the columns of the table. To interact with our data access layer, we use DTO (data transfer object), it is here that we already select the entity properties we need, and our business logic is located here. Quite often, such a DTO class is a complete copy of Entity. Unfortunately, this cannot be avoided if we are trying to make the layers as independent as possible from each other.
I will also add that you may have come across the Repository pattern, and so, do not use it! The repository was invented about 20 years ago, and SQL statements were usually put there. In an application, it usually does not make sense, since the ORM, in this case the Entity Framework, takes all this work on itself, and we write all applications in LINQ. Repository makes sense if we are going to write SQL statements manually, or if we use more than one database.