Ось готовий урок, створений спеціально за твоїм майстер-промптом. Вмикай уяву — ми в лекційній залі Гарварду!

🏛️ CS50: Архітектура даних. Active Record vs Data Mapper

Привіт, світ! 👋 Мене звати Девід, і це... архітектура програмного забезпечення.

Сьогодні ми не просто пишемо код. Ми приймаємо архітектурні рішення. Ми поговоримо про те, як наші об'єкти в коді (Java, Python, PHP, Ruby) "спілкуються" з базою даних. Здавалось би, просто зберегти дані, еге ж?

Але як саме ми це робимо? Хто відповідає за збереження? Сам об'єкт чи хтось інший? Це питання розділяє розробників на два табори вже десятиліттями. Сьогодні ми розберемо Active Record та Data Mapper.

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви — власник ресторану 🍝. У вас є шеф-кухар (це ваш код, бізнес-логіка) і склад продуктів (це ваша база даних).

Коли шеф приготував страву і хоче записати в журнал, що він використав 2 кг помідорів, як це відбувається?

Варіант А: Шеф сам біжить на склад, бере журнал обліку, знаходить потрібну сторінку і вписує туди дані. Він знає, де лежить журнал і як ним користуватися.
Варіант Б: Шеф просто каже: "Гей, менеджер! Я взяв 2 кг помідорів". І спеціальний менеджер складу йде і записує це. Шеф навіть не знає, де той склад знаходиться.

Питання до вас: Який варіант кращий?

Якщо ресторан маленький — варіант А швидший. Але що, якщо склад переїде в іншу будівлю? Шефу доведеться вчити нову дорогу замість того, щоб готувати.

У програмуванні це називається ORM (Object-Relational Mapping). У нас є об'єкти (користувачі, замовлення) і є таблиці в базі. Вони не розуміють одне одного. Нам потрібен посередник. І тут виникає дилема: чи повинен об'єкт сам вміти себе зберігати?

Без розуміння Active Record та Data Mapper ви ризикуєте або перетворити код на спагеті (де все змішано), або настільки ускладнити просту задачу, що на її вирішення підуть тижні. Давайте розберемося!

2. 🧠 Теоретична база (без сухої академічності)

Давайте зазирнемо під капот. Як це працює насправді?

🟢 Active Record (Активний запис)

Це підхід "Все своє ношу з собою".

Суть: Об'єкт класу (наприклад, User) — це точна копія рядка в таблиці бази даних.
Головна фішка: Цей об'єкт має методи .save(), .delete(), .find(). Він "розумний". Він знає про базу даних.
Аналогія: Це як смартфон. У ньому є і ваші фото (дані), і камера, щоб зробити нові, і модуль Wi-Fi, щоб відправити їх у хмару (логіка збереження).

Що запам'ятати: В Active Record клас моделі = дані + логіка доступу до БД. (Популярно в: Ruby on Rails, Laravel, Django).

🔵 Data Mapper (Перетворювач даних)

Це підхід "Розділяй і володарюй".

Суть: Об'єкт User — це просто контейнер для даних (ім'я, email). Він нічого не знає про базу даних. Він навіть не знає, що база даних існує!
Головна фішка: Є окремий "менеджер" (Repository або EntityManager), який бере цей об'єкт і зберігає його.
Аналогія: Це паперовий лист. Лист містить інформацію (дані), але він не може сам себе відправити. Ви маєте кинути його в поштову скриньку (EntityManager), і пошта подбає про доставку.

Що запам'ятати: В Data Mapper сутності (Entities) і логіка збереження повністю розділені. (Популярно в: Java Hibernate, .NET Entity Framework, Doctrine).

3. 🧪 Приклади (від простого до реального)

Давайте подивимось на код. Я хочу, щоб ви зараз уявили, як би ви написали створення нового користувача.

Приклад 1: Active Record 🟢

(Очікування: код має бути дуже коротким і зрозумілим)

# Уявіть, що це Python або схожий псевдокод

# 1. Створюємо об'єкт і наповнюємо даними
user = User()
user.name = "David Malan"
user.email = "malan@harvard.edu"

# 2. Об'єкт САМ себе зберігає!
user.save()

Чому так? Клас User успадковується від базового класу ORM (наприклад, Model). Тому він має магічний метод save(), який генерує SQL-запит INSERT INTO users... прямо всередині цього виклику.

Приклад 2: Data Mapper 🔵

(Очікування: тут має з'явитися хтось третій)

# 1. Створюємо об'єкт (це просто "чистий" клас)
user = User()
user.name = "David Malan"
user.email = "malan@harvard.edu"

# user.save()  <-- ТУТ ЦЕ НЕ СПРАЦЮЄ! Об'єкт не має такого методу.

# 2. Кличемо менеджера
em = EntityManager() # Наш "поштар"
em.persist(user)     # Підготувати до збереження
em.flush()           # Відправити запит в базу (INSERT INTO...)

Чому так? Тут User — це просто Plain Old Object. Ми не засмічуємо його логікою бази даних. Менеджер (em) дивиться на об'єкт, розбирає його і формує SQL.

Приклад 3: Складніша ситуація (Зміна даних)

Уявіть, що нам треба змінити email.

Active Record:

user = User.find(1) # Знайшли по ID
user.email = "new@email.com"
user.save() # Знову сам себе зберіг

Data Mapper:

user = repository.find(1)
user.email = "new@email.com"
# Часто навіть не треба нічого викликати явно, 
# менеджер слідкує за об'єктом і збереже зміни в кінці транзакції (Unit of Work).
em.flush()

4. 🛠 Практична частина

А тепер ваша черга! Вставайте з-за парт (метафорично) і давайте порухаємо нейронами. 🧠

Завдання 1: Детектив Я показую код, ви кажете патерн: order.items.add(pizza); order.calculateTotal(); order.save(); (Відповідь: Active Record — бо order.save())

Завдання 2: Рефакторинг (Active Record) У вас є метод user.save(). Уявіть, що перед збереженням ви хочете завжди переводити email у нижній регістр. Де ви напишете цей код в Active Record? (Підказка: всередині класу User, можливо, перевизначивши метод save або використовуючи хуки)

Завдання 3: "А що, якщо..." (Data Mapper) У вас Data Mapper. Ви змінили структуру таблиці в базі даних (перейменували колонку fullname на full_name). Що вам доведеться змінити в коді? Сам клас User? Чи налаштування мапінгу (конфігурацію)? (Підказка: Клас User можна не чіпати, якщо змінити налаштування того, як поля класу мапляться на колонки БД).

Завдання 4: Міні-кейс Ви пишете скрипт, який має швидко імпортувати 1000 товарів з Excel у базу. Складну бізнес-логіку перевіряти не треба. Який патерн ви оберете для швидкості розробки? (Аргументуйте).

Завдання 5: Пошук помилки Студент написав код на Data Mapper:

user = User()
user.name = "Test"
user.save()

Але отримав помилку Method 'save' not found. Поясніть студенту, чому так сталося, використовуючи аналогію з поштою.

5. 💡 Мислення як у розробника

Як досвідчені інженери приймають рішення? Вони не сперечаються, що "краще". Вони запитують: "Яка складність моєї системи?"

⚠️ Типові помилки новачків:

Active Record у складних системах: Коли ваш клас User має 2000 рядків коду, бо там і валідація, і надсилання пошти, і SQL-запити. Це називається "God Object" (Божественний об'єкт). Це пекло для тестування.
Data Mapper для простого блогу: Ви створюєте 10 файлів конфігурації та сервісів, щоб просто зберегти одну статтю. Це "Overengineering" (надлишкова інженерія).

🧠 Як думає профі:

Active Record — мій вибір для стартапів, прототипів, простих CRUD-додатків (Create, Read, Update, Delete). Це швидко. Раз-два — і в продакшн.
Data Mapper — мій вибір для складних ентерпрайз-систем (банкінг, логістика), де бізнес-логіка складна і має жити окремо від бази даних. Це дозволяє легше писати юніт-тести (бо можна підмінити базу даних заглушкою).

Порада: Якщо ваша модель даних майже 1-в-1 відповідає таблицям у БД — беріть Active Record. Якщо ваші об'єкти сильно відрізняються від структури таблиць — вам потрібен Data Mapper.

6. 🧩 Підсумок

Отже, друзі!

Ми сьогодні розібрали два фундаментальних підходи до роботи з даними: 1. Active Record: Розумні об'єкти, які зберігають самі себе. Швидко, зручно, але тісно пов'язано з базою. 2. Data Mapper: Чисті об'єкти та окремі менеджери. Більше коду, але ідеально для чистої архітектури та тестування.

Тепер ви вмієте: ✅ Розрізняти ці патерни в чужому коді. ✅ Розуміти, чому у Laravel/Rails пишеться так, а в Java/Symonfy — інакше. ✅ Обирати правильний інструмент під задачу.

Але зачекайте... ми навчилися зберігати дані. А як їх ефективно діставати, якщо у нас тисячі записів і зв'язків? На наступному уроці ми розглянемо проблему, яка вбиває продуктивність додатків — The N+1 Problem.

Це був CS50. Побачимось! 👋