Как называется модель, которая хранится строго в БД?

Модель, хранящаяся строго в БД: "Persistent Model" (Персистентная модель) или "Entity" (Сущность)

В контексте разработки программного обеспечения, особенно при использовании ORM (Object-Relational Mapping) и паттернов проектирования, модель, которая хранится строго в базе данных, чаще всего называется Persistent Model (Персистентная модель) или Entity (Сущность). В экосистеме C# и .NET, при работе с Entity Framework Core, это обычно называется "Entity Class" или "Data Model".

Основные характеристики Persistent Model/Entity

Этот тип модели обладает следующими ключевыми признаками:

• Прямое отображение на структуру БД: Каждый класс соответствует таблице, свойства — столбцам, а связи (навигационные свойства) — внешним ключам.
• Наличие ключа: Обязательно имеет свойство, помеченное как первичный ключ (часто Id).
• Отсутствие бизнес-логики: В идеале содержит только данные и минимальные валидации (атрибуты данных), но не содержит сложной бизнес-логики. Это "анемичная модель" в чистом виде.
• Управление жизненным циклом через контекст (DbContext): Ее создание, извлечение, изменение и удаление осуществляется через механизмы ORM.

Практический пример в C# (Entity Framework Core)

Вот как выглядит типичная Entity для таблицы Users:

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace MyApp.Data.Entities
{
    // Класс сущности, напрямую отображаемый на таблицу "Users" в БД.
    [Table("Users")]
    public class User
    {
        // Первичный ключ. Название столбца в БД - "Id".
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        // Столбец "Email". Добавлены атрибуты валидации для уровня БД/EF.
        [Required]
        [MaxLength(255)]
        [EmailAddress]
        public string Email { get; set; }

        // Столбец "FirstName".
        [Required]
        [MaxLength(100)]
        public string FirstName { get; set; }

        // Столбец "LastName".
        [Required]
        [MaxLength(100)]
        public string LastName { get; set; }

        // Столбец "DateOfBirth". Тип в БД - DATE.
        public DateTime DateOfBirth { get; set; }

        // Навигационное свойство: представляет связь "один-ко-многим" с таблицей Orders.
        // Это часть модели, но не прямой столбец в таблице Users.
        public virtual ICollection<Order> Orders { get; set; } = new List<Order>();
    }
}

Эта модель регистрируется в DbContext:

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }

    // DbSet представляет коллекцию сущностей User в БД.
    public DbSet<User> Users { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Здесь можно настроить отображение более детально (Fluent API).
        base.OnModelCreating(modelBuilder);
    }
}

Отличие от других моделей в архитектуре

Чтобы понять важность Persistent Model, стоит сравнить ее с другими типами моделей в современной backend-разработке на C#:

• Domain Model (Доменная модель): Содержит бизнес-логику, инварианты и поведение. Может быть "богатой" (не анемичной). Часто не совпадает один-к-одному с таблицами БД. Используется в ядре приложения по методологиям DDD.
• ViewModel / DTO (Data Transfer Object): Специальные классы для передачи данных между слоями, особенно из API клиенту. Они оптимизированы для конкретных сценариев использования (например, UserProfileDto) и не имеют прямого отношения к схеме БД.
• Command / Query Models: Используются в паттернах CQRS для инкапсуляции данных, необходимых для выполнения команды или запроса.

Таким образом, Persistent Model (Entity) — это именно тот слой объектов, который отвечает исключительно за представление данных в реляционной базе данных и их базовую целостность. Ее главная задача — быть эффективным "мостом" между объектно-ориентированным кодом приложения и реляционной структурой хранения. Использование чистой Entity в качестве универсальной модели для всех задач (бизнес-логики, API) считается антипаттерном, так как приводит к сильному зацеплению слоев и усложнению поддержки. Поэтому в профессиональной разработке она часто служит основой, из которой маппятся (например, с помощью AutoMapper) более специализированные DTO и ViewModel для бизнес-уровня и уровня представления.