Що таке ORM? Від SQL до об'єктів

Код, якого ви хотіли б уникнути

Уявіть звичайне завдання: отримати список активних замовлень конкретного клієнта разом з інформацією про продукти. Ви вже пройшли розділ ADO.NET, тому знаєте, як це виглядає насправді:

public async Task<List<OrderDto>> GetActiveOrdersAsync(int customerId)
{
    var orders = new List<OrderDto>();

    const string sql = @"
        SELECT o.Id, o.CreatedAt, o.TotalAmount, o.Status,
               oi.Id AS ItemId, oi.Quantity, oi.UnitPrice,
               p.Id AS ProductId, p.Name AS ProductName, p.Sku
        FROM Orders o
        INNER JOIN OrderItems oi ON oi.OrderId = o.Id
        INNER JOIN Products p ON p.Id = oi.ProductId
        WHERE o.CustomerId = @customerId
          AND o.Status = 'Active'
        ORDER BY o.CreatedAt DESC";

    await using var connection = new SqlConnection(_connectionString);
    await connection.OpenAsync();

    await using var command = new SqlCommand(sql, connection);
    command.Parameters.AddWithValue("@customerId", customerId);

    await using var reader = await command.ExecuteReaderAsync();

    var orderMap = new Dictionary<int, OrderDto>();

    while (await reader.ReadAsync())
    {
        var orderId = reader.GetInt32(reader.GetOrdinal("Id"));

        if (!orderMap.TryGetValue(orderId, out var order))
        {
            order = new OrderDto
            {
                Id        = orderId,
                CreatedAt = reader.GetDateTime(reader.GetOrdinal("CreatedAt")),
                Total     = reader.GetDecimal(reader.GetOrdinal("TotalAmount")),
                Status    = reader.GetString(reader.GetOrdinal("Status")),
                Items     = new List<OrderItemDto>()
            };
            orderMap[orderId] = order;
        }

        order.Items.Add(new OrderItemDto
        {
            Id          = reader.GetInt32(reader.GetOrdinal("ItemId")),
            Quantity    = reader.GetInt32(reader.GetOrdinal("Quantity")),
            UnitPrice   = reader.GetDecimal(reader.GetOrdinal("UnitPrice")),
            ProductId   = reader.GetInt32(reader.GetOrdinal("ProductId")),
            ProductName = reader.GetString(reader.GetOrdinal("ProductName")),
            Sku         = reader.GetString(reader.GetOrdinal("Sku"))
        });
    }

    return orderMap.Values.ToList();
}

Цей код правильний. Він працює. Але подивіться, скільки тут роботи, яка не має жодного відношення до бізнес-логіки: відкрити connection, написати SQL-рядок вручну, передати параметри, прочитати рядки через reader.GetInt32(), вручну зібрати об'єктний граф із плоского набору рядків. І це лише один запит.

Тепер уявіть, що таких запитів у проєкті сотні. Кожного разу — одне й те саме: з'єднання, параметри, ручне маппінг. А якщо поле в базі перейменовано — доведеться переписати всі рядки-рядки в кожному методі.

Саме з цієї проблеми виросла концепція Object-Relational Mapping.

Impedance Mismatch: корінь усіх бід

У 1990-х роках, коли об'єктно-орієнтоване програмування стало мейнстрімом, а реляційні бази даних вже міцно стояли в індустрії, розробники зіткнулися із фундаментальним протиріччям. У програмуванні ми мислимо об'єктами — сутностями зі стан, поведінкою і зв'язками. Реляційні бази даних зберігають дані у вигляді таблиць і рядків — плоских, нормалізованих структур без поведінки.

Це протиріччя отримало назву Object-Relational Impedance Mismatch — невідповідності між об'єктною та реляційною моделями даних. Термін популяризував Мартін Фаулер у своїй фундаментальній книзі «Patterns of Enterprise Application Architecture» (2002).

Ця невідповідність проявляється у п'яти конкретних проблемах, кожна з яких щодня нагадує про себе в коді без ORM:

Проблема 1: Типи даних

У C# є DateTime, Guid, decimal, enum, nullable types, value types. У SQL — DATETIME, UNIQUEIDENTIFIER, NUMERIC(18,2), INT. Перетворення між ними не завжди тривіальне: SQL Server зберігає DateTime з точністю до мілісекунди, але може відрізатися від DateTime у CLR через округлення. PostgreSQL має окремий тип timestamptz з інформацією про часовий пояс. Enum у C# зберігається як ціле число, але у базі може бути і INT, і VARCHAR.

Проблема 2: Ідентичність

У C# ідентичність об'єкта визначається за посиланням (reference equality): два різних об'єкти з однаковими даними — це два різних об'єкти. У реляційній базі ідентичність визначається первинним ключем: два рядки з однаковим PK — це один і той самий рядок. Якщо ви двічі запитаєте один рядок з БД, ви отримаєте два різних C#-об'єкти, і це може призвести до неочікуваної поведінки при порівнянні.

Проблема 3: Зв'язки

У C# зв'язки виражаються через навігаційні властивості: Order.Customer, Customer.Orders. Це двосторонні посилання. У SQL зв'язки виражаються через зовнішні ключі — числові значення в одній таблиці, що вказують на рядок в іншій. JOIN у SQL є явним і виконується при запиті. У C# доступ до order.Customer виглядає як просте звернення до властивості.

Проблема 4: Навігація (N+1 проблема)

Якщо у вас є список з 100 замовлень і ви хочете дізнатися ім'я клієнта для кожного, в SQL ви зробите один JOIN. В об'єктній моделі без ORM ви можете ненавмисно написати цикл, що робить 100 окремих запитів до бази — по одному на кожне замовлення. Це класична N+1 проблема, яка руйнує продуктивність.

Проблема 5: Гранулярність

В ООП є смисл виділити дрібні класи з відповідальністю — наприклад, окремий клас Address з полями Street, City, ZipCode. Але у базі це зазвичай зберігається як набір окремих стовпців у таблиці Customers: Street, City, ZipCode. Тобто одна C# властивість (Address) відповідає декільком стовпцям БД.

Визначення: що таке ORM?

Object-Relational Mapping (ORM) — це патерн і технологія, що автоматизує перетворення між об'єктною моделлю застосунку та реляційною моделлю бази даних, зберігаючи при цьому семантику обох.

Мартін Фаулер у «P of EAA» описує ORM як підклас патерну Data Mapper — об'єкта, що відповідає за переміщення даних між об'єктами та базою даних, зберігаючи їх незалежними один від одного та від mapper'а.

Ключове слово тут — незалежними. Це означає, що ваш клас Order не повинен знати, як він зберігається в базі. Він є чистою C#-сутністю з властивостями і поведінкою. ORM-фреймворк відповідає за те, щоб «перекласти» цю сутність у SQL при збереженні і «перекласти назад» при читанні.

Розберемо, як виглядає та сама операція з ORM (Entity Framework Core):

public async Task<List<Order>> GetActiveOrdersAsync(int customerId)
{
    return await _context.Orders
        .Where(o => o.CustomerId == customerId && o.Status == OrderStatus.Active)
        .Include(o => o.Items)
            .ThenInclude(item => item.Product)
        .OrderByDescending(o => o.CreatedAt)
        .ToListAsync();
}

Це — той самий запит. Той самий JOIN. Той самий фільтр і сортування. Але тепер ми працюємо з об'єктами C# безпосередньо. ORM автоматично транслює LINQ-вираз у SQL, виконує запит і матеріалізує результат у повноцінний граф об'єктів Order → Items → Product.

Еволюція доступу до даних у .NET

Щоб зрозуміти, чому і як з'явились ORM-фреймворки, варто простежити хронологію:

timeline
    title Еволюція доступу до даних у .NET
    2002 : ADO.NET
         : Ручний SQL та DataReader
         : Повний контроль, максимум коду
    2004 : NHibernate 1.0
         : Перший ORM для .NET
         : Порт Hibernate з Java
    2008 : LINQ to SQL
         : Вбудований ORM від Microsoft
         : Тільки SQL Server, обмежений
    2008 : Entity Framework 1.0
         : Повноцінний ORM від Microsoft
         : XML-конфігурація, складний
    2012 : EF 5 / Code First
         : Революція — модель через код
         : Без XML, тільки C#
    2016 : EF Core 1.0
         : Переписано з нуля
         : Кросплатформний, модульний
    2019 : EF Core 3.1
         : Зрілий LTS-реліз
         : Стабільна основа
    2023 : EF Core 8 / 9
         : JSON Columns, Complex Types
         : Сучасний EF Core

ADO.NET (2002) — фундамент, який ви вже знаєте. Він дає максимальний контроль над кожним SQL-запитом. Але це означає максимум ручної роботи: з'єднання, команди, reader, маппінг.

LINQ to SQL (2008) — перший ORM від Microsoft, але обмежений тільки SQL Server і з часом фактично припинив розвиток.

Entity Framework (2008–2012) — початкові версії мали репутацію «важкого» фреймворку з XML-конфігурацією і незрілим генератором SQL. Версія з Code First (2012) стала переломним моментом.

EF Core (2016–досі) — повна переробка з нуля. Кросплатформний (Linux, macOS), модульний, з підтримкою безлічі провайдерів БД. Саме EF Core є предметом цього курсу.

Патерни доступу до даних: Active Record vs Data Mapper

Перш ніж говорити про конкретні інструменти, важливо розуміти два фундаментальних патерни — вони визначають архітектурний підхід ORM-фреймворку.

// Rails-стиль Active Record
var order = Order.Find(42);
order.Status = "Completed";
order.Save(); // зберігає себе сам

// Data Mapper стиль
var order = await _context.Orders.FindAsync(42); // mapper читає
order.Status = OrderStatus.Completed;
await _context.SaveChangesAsync(); // mapper зберігає

Entity Framework Core реалізує патерн Data Mapper. DbContext — це і є той самий mapper, який читає і зберігає ваші чисті POCO-класи (Plain Old CLR Objects). Самі класи Order, Product, Customer нічого не знають про базу даних — вони є чистими C#-об'єктами.

Це критично важливо для тестування: ваші сервіси та доменні класи можна тестувати без жодної реальної бази даних.

Ландшафт ORM у .NET: що обирати?

Сьогодні в екосистемі .NET є кілька зрілих варіантів для доступу до даних. Розберемо кожен:

Entity Framework Core

Офіційний ORM від Microsoft, частина .NET екосистеми. Підтримує Code First, Database First, міграції, LINQ-запити, зміну відслідковування (change tracking).

Підходить для: більшості корпоративних застосунків, CRUD-інтенсивних проєктів, команд зі стандартними вимогами.

Dapper

Мікро-ORM, написаний командою Stack Overflow. Фактично є extension methods для IDbConnection, що дозволяє зручно виконати SQL і отримати результат як C#-об'єкти.

// Dapper: все ще SQL, але маппінг автоматичний
var orders = await connection.QueryAsync<Order>(
    "SELECT * FROM Orders WHERE CustomerId = @id AND Status = 'Active'",
    new { id = customerId }
);

Підходить для: high-performance сценаріїв, коли потрібен повний контроль над SQL, legacy-бази зі складною схемою, аналітичні запити.

NHibernate

Зрілий, дуже функціональний ORM — порт Hibernate з Java. Має більший feature set, ніж EF Core (наприклад, second-level cache, більш гнучке маппінгу). Але значно складніший у налаштуванні.

Підходить для: складних доменних моделей (DDD), коли потрібні можливості, яких немає в EF Core.

LINQ to DB

Lightweight ORM з детальним контролем над SQL та відмінною підтримкою різних провайдерів.

EF Core vs Dapper: детальне порівняння

Це найчастіше питання в .NET-спільноті. Правильна відповідь: обидва можна використовувати в одному проєкті — для різних задач.

var expensive = await _context.Products
    .Where(p => p.Price > 1000 && p.Category == "Electronics")
    .OrderBy(p => p.Name)
    .Select(p => new { p.Id, p.Name, p.Price })
    .ToListAsync();

var expensive = await connection.QueryAsync<ProductDto>(
    @"SELECT Id, Name, Price FROM Products
      WHERE Price > @minPrice AND Category = @category
      ORDER BY Name",
    new { minPrice = 1000, category = "Electronics" }
);

Чому Entity Framework Core?

З усіх варіантів ми вивчатимемо саме EF Core. Ось чому:

1. Офіційна підтримка Microsoft. EF Core є частиною .NET-екосистеми, розвивається тією ж командою. Кожен реліз .NET супроводжується новим мажорним релізом EF Core.

2. Найширший функціонал серед .NET ORM. Change Tracking, міграції, LINQ-трансляція, Owned Types, JSON Columns, Interceptors, Compiled Queries — EF Core є найбільш повнофункціональним інструментом.

3. Кросплатформність. Підтримує будь-який .NET-провайдер баз даних: PostgreSQL (Npgsql), SQL Server, MySQL, SQLite, Cosmos DB.

4. Стандарт індустрії. Переважна більшість вакансій .NET-розробника вимагає знання EF Core. Це загальна мова команди.

5. Активна спільнота та документація. Офіційна документація Microsoft — одна з найкращих у .NET-просторі.

Де живе EF Core в архітектурі?

Перш ніж зануритись у код, важливо зрозуміти, яке місце EF Core займає в типовій архітектурі .NET-застосунку:

graph TD
    subgraph "Presentation Layer"
        A["🌐 Controllers / Endpoints<br/>Razor Pages / Blazor"]
    end

    subgraph "Application Layer"
        B["📋 Application Services<br/>Command Handlers / Queries"]
    end

    subgraph "Domain Layer"
        C["📦 Domain Entities<br/>Order, Product, Customer"]
        D["🔄 Domain Services<br/>OrderService, PricingService"]
    end

    subgraph "Infrastructure Layer"
        E["🗄️ DbContext<br/>AppDbContext"]
        F["📁 Repositories<br/>IOrderRepository"]
        G["🔌 EF Core<br/>+ Database Provider"]
    end

    subgraph "Database"
        H[("💾 PostgreSQL<br/>SQL Server<br/>SQLite")]
    end

    A --> B
    B --> D
    B --> F
    D --> C
    F --> E
    E --> G
    G --> H

    style G fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style E fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style H fill:#64748b,stroke:#334155,color:#ffffff

EF Core живе в Infrastructure Layer (шарі інфраструктури). Він є деталлю реалізації, яку можна замінити (наприклад, перейти з SQL Server на PostgreSQL), не зачіпаючи доменну логіку. Доменні сутності (Order, Product) — у Domain Layer і нічого не знають про EF Core.

Ця архітектурна ізоляція є принципово важливою. Саме тому EF Core реалізує патерн Data Mapper, а не Active Record: ваш Order — чиста C# модель без жодного атрибуту чи залежності від фреймворку доступу до даних.

Концепція "Code First": модель через код

EF Core підтримує два основних підходи:

Code First — ви описуєте модель у C# класах, EF Core генерує схему бази даних (через міграції). Це рекомендований підхід для нових проєктів.

Database First — ви маєте існуючу базу, EF Core scaffold-ує C# класи з неї. Підходить для роботи з legacy-базами.

У цьому курсі ми зосередимось на Code First як основному підході. Ось як виглядає проста модель:

public class Order
{
    public int Id { get; set; }
    public DateTime CreatedAt { get; set; }
    public decimal TotalAmount { get; set; }
    public OrderStatus Status { get; set; }

    public int CustomerId { get; set; }
    public Customer Customer { get; set; } = null!;

    public ICollection<OrderItem> Items { get; set; } = new List<OrderItem>();
}

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

    public DbSet<Order> Orders => Set<Order>();
    public DbSet<Customer> Customers => Set<Customer>();
    public DbSet<Product> Products => Set<Product>();
}

Це — весь код, необхідний для початку роботи. EF Core за конвенцією визначить таблиці, первинні ключі, зовнішні ключі. Рядків XML-конфігурації — нуль.

"Магічний" запит зсередини

Давайте подивимось, що насправді відбувається, коли EF Core виконує LINQ-запит:

var orders = await _context.Orders
    .Where(o => o.CustomerId == 5 && o.Status == OrderStatus.Active)
    .Include(o => o.Items)
    .ToListAsync();

SELECT o.Id, o.CreatedAt, o.TotalAmount, o.Status, o.CustomerId,
       oi.Id, oi.OrderId, oi.ProductId, oi.Quantity, oi.UnitPrice
FROM Orders AS o
LEFT JOIN OrderItems AS oi ON oi.OrderId = o.Id
WHERE o.CustomerId = 5 AND o.Status = 1

Вся ця складна механіка прихована від вас. Ви пишете LINQ, отримуєте C#-об'єкти. Але розуміння того, що відбувається «під капотом», критично важливе для написання ефективного коду — і саме тому ми розберемо кожен з цих кроків детально в наступних статтях.

Аргументи проти ORM (і відповіді на них)

Справедливість вимагає розглянути і критику ORM. Ці аргументи реальні, і їх важливо розуміти:

Що далі: дорожня карта цього курсу

Ви тепер розумієте, звідки виникла проблема, що таке ORM концептуально і чому EF Core є правильним вибором для більшості .NET-проєктів. Це — теоретичний фундамент.

Решта курсу — це послідовне заглиблення у практику:

Практичні завдання

Підсумок

Наступна стаття — Перший проєкт: від нуля до CRUD — практика: встановлення, перший DbContext, перші міграції та повноцінний CRUD з нуля.