Модель у Laravel (Eloquent) — це “обличчя” таблиці в коді. Вона дозволяє читати та записувати дані без ручного SQL, описувати зв’язки і додавати правила роботи з атрибутами. Але модель не робить дані “безпечними” автоматично. Якщо ти не налаштуєш fillable/guarded, casts та accessors/mutators, ти легко отримаєш уразливості, некоректні типи, хаос з форматами і баги, які потім дуже важко ловити.
Почнемо з найнебезпечнішого — mass assignment, тобто “масове заповнення” полів. Коли ти робиш Model::create($data) або $model->update($data), ти передаєш масив, і Laravel намагається заповнити поля з цього масиву. Якщо ти бездумно передаєш туди весь $request->all(), користувач може підсунути зайві поля, які ти не планував змінювати: наприклад is_admin, created_by, approval_status, subscription_required або будь-яке службове поле. Це класична дірка, через яку “звичайний” користувач може змінити те, що не мав права змінювати.
fillable — це білий список дозволених полів для масового заповнення. Тобто ти явно кажеш: “ці поля можна приймати масово, інші — ігнорувати”. Для новачка це найкраща дисципліна, бо вона змушує думати, які поля реально мають прийти з форми або API. Якщо поле не повинно редагуватися ззовні, воно не повинно бути в fillable. Це правило захищає навіть тоді, коли десь помилково передали зайві дані.
guarded — це чорний список полів, які не можна масово заповнювати. Часто його ставлять як ['id'] або навіть роблять guarded = [] (дозволити все). Для комерційних і адмінських систем guarded = [] — це поганий варіант, бо він знімає захист і робить будь-яку помилку у контролері або сервісі небезпечною. Як стандарт для живого проєкту: або використовуй fillable як білий список, або дуже обережно guarded, але без “дозволити все”.
Правильний практичний підхід такий: у моделі дозволяєш масово лише те, що реально редагується з UI. Наприклад, у “новині” це може бути title, desc, content, main_image, published_at, topic_id, section_id. Але поля типу created_by, approved_by, approval_status, views, is_featured або технічні прапорці ти або виставляєш програмно, або перевіряєш окремими правилами, а не “заливаєш” з request.
Далі casts — це про типи. База даних зберігає дані як рядки/числа/дата-типи, а PHP часто бачить це як рядок. Касти кажуть Laravel: “коли ти читаєш це поле, перетвори його в потрібний тип”. Це критично для boolean, datetime та масивів. Без casts ти починаєш ловити дивні штуки: '0' поводиться як true в умовах, дати стають рядками, а JSON-поля — просто текстом.
Найчастіші casts у реальному проєкті — boolean, integer, float/decimal, datetime/date, array/json. Якщо поле live або subscription_required — це boolean, воно має повертатися як справжній true/false, а не '0'/'1'. Якщо поле published_at — дата, ти хочеш отримати об’єкт дати, щоб порівнювати і форматувати його нормально. Якщо поле зберігає масив (наприклад, налаштування або список), ти хочеш бачити в коді масив, а не JSON-рядок.
Касти — це не “прикраса”, а спосіб уникнути тихих логічних багів. Коли ти робиш умову if ($news->live), ти хочеш, щоб це було чесне true/false. Коли ти рахуєш суму або порівнюєш числа, ти не хочеш порівнювати рядки. Коли ти працюєш з датами, ти не хочеш вручну парсити формат кожного разу. Все це вирішується casts в одному місці.
Тепер accessors і mutators — це контроль трансформацій атрибутів. Accessor — це те, як поле виглядає при читанні. Mutator — це те, як поле приводиться при записі. Їх сила в тому, що ти можеш централізовано нормалізувати дані, не розмазуючи цю логіку по контролерах і сервісах.
Accessor корисний, коли треба сформувати “похідне” значення або стандартизувати формат для UI. Наприклад, ти можеш зробити accessor для повного URL картинки, щоб в шаблоні не робити 10 умов. Або accessor для “короткого опису”, щоб не дублювати обрізку тексту. Але тут важливо не зловживати: accessor має бути про представлення, а не про бізнес-рішення.
Mutator корисний, коли ти хочеш гарантувати нормалізацію на вході. Наприклад, ти завжди хочеш тримати slug у нижньому регістрі без пробілів, або прибирати зайві пробіли з заголовка, або зберігати email в нижньому регістрі. Тоді mutator робить це автоматично кожного разу, коли поле записують, і тобі не треба пам’ятати “перед збереженням зроби trim”.
Є важливе правило безпеки: mutator не повинен приховано міняти дані так, щоб це ламало бізнес-логіку. Нормалізувати пробіли, регістр, формат — ок. Але автоматично “публікувати” запис або змінювати статуси в mutator — погано, бо це неочевидна поведінка і її важко відстежити.
Так само треба розуміти різницю між casts і mutators. Casts — це про типи, вони роблять дані зручними для використання. Mutators — про контроль того, як дані записуються. Ти можеш мати published_at як datetime cast, а mutator може додатково нормалізувати часову зону або формат вхідного значення, якщо це потрібно. Але не змішуй ці речі в одну “магію”.
Практична схема, яка працює в більшості проєктів. У моделі ти ставиш fillable як білий список для полів, які приходять з форми. Далі додаєш casts для boolean, дат і масивів, щоб не ловити тихі баги. Після цього додаєш кілька mutators для базової нормалізації (trim, lower, slugify). Accessors використовуєш обережно, щоб зробити шаблони чистішими, але не ховати важливу логіку від команди.
Висновок: Eloquent-модель — це не просто “клас для таблиці”, а місце, де ти фіксуєш правила безпеки і стабільності даних. fillable/guarded захищає від небезпечного масового заповнення, casts робить типи чесними і передбачуваними, а accessors/mutators дозволяють централізовано і акуратно трансформувати дані. Якщо ти зробиш це стандартом, твій код стане простішим, а база — чистішою, навіть коли система почне рости.
