require та include для ізоляції файлів.До цього етапу ми писали код “в лоб” (шлях новачка). У кожному нашому файлі (наприклад, index.php) ми підключалися до бази даних, відразу ж писали SQL-запит на витягування завдань і нижче, у цьому ж файлі, відкривали теги <!DOCTYPE html>, де через цикли виводили ці завдання.
Коли проєкт розростається до тисяч рядків, такий підхід перетворює скрипт на некерований “Спагетті-код”. Змінити дизайн меню стає неможливо без ризику зламати логіку бази даних. У цій лекції ми навчимось професійному розділенню: як зробити так, щоб логіка калькуляцій жила окремо від візуального відображення сторінки.
Уявіть класичний файл index.php початківця:
<?php
// ТУТ БАЗА
$pdo = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$stmt = $pdo->query("SELECT * FROM users");
$users = $stmt->fetchAll(PDO::FETCH_ASSOC);
// ТУТ ВАЛІДАЦІЯ
if (isset($_POST['name'])) {
if (strlen($_POST['name']) < 3) echo "Помилка!";
}
?>
<!-- ТУТ ДИЗАЙН -->
<html>
<body>
<h1>Користувачі</h1>
<?php foreach($users as $u): ?>
<p><?= $u['name'] ?></p>
<?php endforeach; ?>
</body>
</html>
Чому це погано?
$pdo->query, намагаючись просто змінити колір заголовка <h1>.index.php роздується до 500 рядків, де логіка перемішана з тегами <div>.Щоб навести лад, світова спільнота інженерів домовилась розділяти будь-який застосунок на 3 незалежні шари. Цей підхід назвали MVC.
$users, і я просто намалюю його красивими картками на екрані”. View ніколи не робить запитів до Бази Даних (Не містить SQL).GET ?page=home), каже Моделі: “Дай мені 10 завдань”, забирає ці завдання і передає їх у Вигляд зі словами: “А тепер намалюй їх”.У межах поточного курсу ми не можемо одразу побудувати повноцінний ООП-фреймворк, але ми можемо застосувати Принцип MVC (Поділ інтересів) на базових інструментах PHP.
require та include для ізоляції файлівЩоб розділити наш єдиний файл на “Логіку” та “Шаблон”, ми використаємо дві команди PHP, які вміють “вклеювати” один файл усередину іншого:
include 'view.php'; (Включити)
Спробує завантажити файл view.php. Якщо файл не знайдено — видасть жовте попередження (Warning), але робота скрипта продовжиться. Використовується рідко, здебільшого для некритичних рекламних блоків чи віджетів.require 'view.php'; (Вимагати)
Строга версія. Якщо файл не знайдено — генерується критична помилка (Fatal Error) і скрипт миттєво гине. Це ідеально для наших шаблонів та конфігів баз даних.Давайте проведемо Рефакторинг (перепишемо архітектуру) нашого списку завдань згідно з філософією MVC.
Створіть папку views/ і в ній файл task_list.php.
Сюди ми переносимо ТІЛЬКИ HTML. Цей файл не знає, звідки беруться завдання, він просто розраховує, що змінна $tasks вже існує в пам’яті.
views/task_list.php (Вигляд):
<!DOCTYPE html>
<html lang="uk">
<body style="font-family: sans-serif;">
<h1>Мої Завдання</h1>
<ul class="task-list">
<!-- Ми робимо лише рендеринг, жодних підключень до бази! -->
<?php foreach($tasks as $t): ?>
<li>
<?= htmlspecialchars($t['title']) ?> (Статус: <?= $t['is_done'] ?
'Виконано' : 'В процесі' ?>)
</li>
<?php endforeach; ?>
</ul>
</body>
</html>
Наш старий index.php тепер стає чистим Контролером. З нього назавжди зникають теги <html> і відтепер він містить виключно PHP логіку.
index.php (Контролер):
<?php
// 1. ПІДКЛЮЧЕННЯ (Частина Моделі)
require_once 'db.php';
// 2. БІЗНЕС-ЛОГІКА (Контролер просить Модель дати дані)
$stmt = $pdo->query("SELECT * FROM tasks ORDER BY id DESC");
// Формуємо масив $tasks.
// Увага: Змінна $tasks зараз оживає в оперативній пам'яті сервера!
$tasks = $stmt->fetchAll(PDO::FETCH_ASSOC);
// 3. ПЕРЕДАЧА ДАНИХ У ВИГЛЯД (Рендеринг)
// Скрипт зупиняється, "викликає" файл шаблону.
// Оскільки змінна $tasks була оголошена РЯДКОМ ВИЩЕ,
// файл task_list.php буде чудово її "бачити" і зможе перебрати в foreach!
require_once 'views/task_list.php';
?>
Тепер, якщо ми хочемо найняти дизайнера для зміни кольору кнопок чи шрифту, ми кажемо йому: “Працюй тільки в папці views/. Основні файли (там де паролі від БД) не чіпай”.
Якщо настав час оптимізувати SQL-запити — Backend-розробник відкриває свій index.php і спокійно пише логіку, не відволікаючись на сотні рядків <div> і <style>.
Це найпростіша і найважливіша еволюція мислення від “кодувальника” до “інженера-архітектора”.
require або include. Вони дозволяють склеювати різні файли в один цілісний потік під час виконання, передаючи всі ініціалізовані змінні з контролера до шаблону.products.php на 800 рядків, де перемішані SQL-запити до кошика товарів, CSS-стилі, та HTML-розмітка заголовків. Вкажіть щонайменше дві критичні проблеми, з якими стикнеться ваша команда, якщо доведеться терміново змінити дизайн кнопок кошика, не поламавши бази даних? Назвіть термін цього хаосу.MVC (Model, View, Controller). Який саме файл відповідає за підключення до Бази і збереження Завдання згідно з цією архітектурою, а який зобов’язаний бути абсолютно “чистим” від SQL і містити тільки <!DOCTYPE html>?index.php), який успішно дістав масив користувачів з Бази Даних у змінну $users_list, може поділитися (передати) цими даними з окремим файлом дизайну (наприклад views/users.php)? Чому файл дизайну “бачить” цю змінну, хоча в ньому вона не оголошувалася?include 'shablon.php' та require 'shablon.php'? Які наслідки очікують користувача, якщо цей файл shablon.php був колись випадково видалений з сервера, в обох випадках технологій підключення?require 'views/list.php';) виключно у самому кінці Контралера (найнижчим рядком). Чому підключати Вигляд перед виконанням запитів до Бази ($pdo->query) логічно неправильно і призведе до фатальних помилок при рендерингу $tasks всередині Шаблону?