Как называется класс модели, который напрямую сопоставляется с таблицей базы данных в Entity Framework?

Давай разжую эту тему, как будто объясняю за соседним столом в общаге, пока чайник кипит.

Смотри, есть у тебя обычный класс, так, ничем не примечательный. Ну, свойства, поля — хуйня. Это и есть Сущность (Entity). По сути, это просто твой POCO-класс, который EF Core хватает за жопу и тащит в базу данных, как будто это его законная собственность.

Что с ней делает EF Core, этот хитрожопый фреймворк? Он её отслеживает. Создал ты объект, добавил в контекст — он за ним глаз да глаз. Изменил свойство — EF Core это заметит и при сохранении в базу всё аккуратно обновит. Это не какой-то там DTO, который послали и забыли. Сущность — она под колпаком.

Как она в базе оказывается? Обычно один такой класс — это одна таблица в базе. Свойства — это столбцы. Всё это можно настроить: либо по умолчанию (EF Core многое сам догадается), либо атрибутами, либо через Fluent API — это как удобнее.

Главное, без чего не жить:

1. Ключ. Надо ему свойство, которое будет первичным ключом. Чаще всего это Id или ProductId. Без этого — пиздец, EF Core начнёт нервно курить и спрашивать «а где, блядь, ключ?».
2. Навигационные свойства. Вот это магия. Через них ты описываешь связи между таблицами. Типа, у Product есть Category. Это не просто int CategoryId, а ссылка на целый объект-категорию. Или коллекция OrderItems. EF Core по этим ссылкам сам JOIN'ы строит и графы объектов подтягивает. Красота, хотя иногда и головная боль.

Вот смотри, пример, как это выглядит в коде:

// Это наш класс-сущность. Будет таблица "Products" в базе.
public class Product
{
    // Ключ. EF Core увидит "Id" и поймёт всё сам. Автоинкремент, красота.
    public int Id { get; set; }

    // Простые свойства — станут столбцами.
    public string Name { get; set; }
    public decimal Price { get; set; }
    public bool IsInStock { get; set; }

    // Внешний ключ. По умолчанию ищет свойство с именем <НавигационноеСвойство>Id.
    public int CategoryId { get; set; }

    // Навигационное свойство. Связь "многие к одному". Виртуальное — для ленивой загрузки.
    public virtual Category Category { get; set; }

    // А это связь "один ко многим". Заказы, где этот товар фигурирует.
    public virtual ICollection<OrderItem> OrderItems { get; set; } = new List<OrderItem>();
}

// А вот так мы эту сущность регистрируем в контексте — главной точке входа EF Core.
public class AppDbContext : DbContext
{
    // DbSet — это и есть представление таблицы в коде.
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }
    // ... и так далее
}

Важный момент, чтобы не облажаться: Не путай сущность с другой хуйнёй, которую тоже называют «моделями».

• DTO (Data Transfer Object): Это как конверт для данных. Кинул туда-сюда, распаковал, выбросил. Никакого отслеживания, никакой сложной вложенности. Плоский и простой.
• ViewModel: Это уже для интерфейса. Туда можешь намешать всего: и из сущности Product поля, и из Category название, и ещё какую-нибудь хуйню, нужную для отрисовки страницы.
• Модель предметной области (Domain Model): Это более крутая версия сущности. Она не только данные хранит, но и поведение (методы) с бизнес-правилами внутри. Твоя EF Core-сущность может быть такой моделью, но часто это просто болванка для базы.

Совет из окопа: Если проект не игрушечный, то часто делают так: доменная модель (с мозгом) живёт отдельно, а для EF Core заводят туповатую сущность-копию, только для сохранения в базу. Потом между ними маппером (типа AutoMapper) данные перегоняют. Больше писанины, зато голова не болит от того, что требования базы и бизнес-логики лезут друг другу в пасть.