Питання на співбесіду Yii

Yii2-застосунок - це один обʼєкт `Yii::$app`, створений вхідним скриптом `web/index.php` з масиву конфігурації: він піднімає аліаси й error handler, виконує `bootstrap`, просить `UrlManager` розібрати URL на маршрут, за маршрутом знаходить модуль, контролер і дію, а результат віддає через компонент `response`.

ActiveRecord у Yii2 — це надбудова над Query Builder: `ActiveQuery` успадковує `yii\db\Query`, будує той самий SQL, але замість масивів повертає обʼєкти моделей із валідацією, подіями, поведінками й звʼязками; Query Builder беруть там, де обʼєкти не потрібні — агрегати, звіти, масові операції.

`rules()` описує, що і як перевіряти, `scenarios()` - які атрибути активні в поточному сценарії й котрі з них safe; `load()` присвоює лише safe-атрибути, тому поле без жодного правила (або з `!` у сценарії) у модель просто не потрапить.

Yii3 переписали з нуля: кілька десятків незалежних пакетів `yiisoft/*` замість монолітного фреймворка, DI-контейнер і конструктори замість глобального `Yii::$app`, PSR-15 middleware замість фільтрів-поведінок, PSR-3/6/7/11/14/15/16/17/18 замість власних інтерфейсів. Частина пакетів давно стабільна й працює в будь-якому PHP-проєкті, але повного стека зі стабільним релізом станом на зараз немає, тому будувати плани продукту навколо очікування Yii3 не варто.

Event — точка розширення в `yii\base\Component`: клас викликає `trigger()`, а зовнішній код підписується через `on()`. Behavior — обʼєкт, який прикріплюється до компонента в рантаймі, підписує свої методи на події через `events()` і додає компоненту власні властивості й методи через `__get`/`__call`. Разом вони дають повторне використання поведінки без успадкування.

У Yii2 два різні реєстри: `Yii::$container` (DI-контейнер, резолвить конструктори через рефлексію і за замовчуванням віддає новий обʼєкт) і ServiceLocator застосунку з секції `components` (ліниві синглтони на запит, доступні як `Yii::$app->db`). Обидва створюють обʼєкти через `Yii::createObject()`, тому конфіг у Yii2 це масив із `class` плюс публічні властивості, а не набір closure-привʼязок, як у Laravel.

RBAC у Yii2 будується на ієрархії ролей і дозволів з правилами: ієрархія зберігається в БД або файлі, перевірка йде через Yii::$app->user->can(), а правила додають динамічні умови на кшталт авторства.

У Yii2 чотири рівні: кеш даних через компонент `cache` (`get`/`set`/`getOrSet`), кеш фрагментів через `beginCache()`/`endCache()`, кеш сторінок фільтром `yii\filters\PageCache` і HTTP-кеш фільтром `yii\filters\HttpCache` з `Last-Modified`/`ETag`. Інвалідація - або за часом, або через обʼєкт `Dependency`: `DbDependency` перевіряє результат дешевого SQL, `TagDependency` позначає групу ключів застарілою через `TagDependency::invalidate()`.

Найбезпечніший підхід — strangler pattern: новий застосунок ставиться поруч, роутинг поступово перекидається на нього, спільною лишається база даних; переписувати все одразу означає роками тримати дві версії продукту.