1. Содержание
1.1. Фреймворко-независимый код
1.1.1. Зачем нужен фреймворк?
1.1.1.1. Поднятие окружения с нуля
1.1.1.2. Готовность принять Request и отдать Response
1.1.1.3. Управление зависимостями
1.1.1.4. Прочие вспомогательные инструменты фреймворка: авторизация, управление ролями и правами доступа, работа с файлами, работа с кешем, роутинг, прочее
1.1.2. Где фреймворк не нужен?
1.1.2.1. Кейс с QueryBuilder'ом от Олега Кретинина
1.1.2.1.1. На собеседование приходят люди, которые без понятия, как написать голый SQL запрос, без использования QueryBuilder'а фреймворка. Абсурдная ситуация, но стоит иметь ввиду
1.1.2.2. Бизнес-логика
1.1.2.2.1. Бизнес-логика - наивысший уровень слоя абстракций кода
1.1.2.2.2. Бизнес-логика имеет свойство кочевать из проекта в проект
1.1.2.2.3. В бизнес-правилах ни слова не говорится о фреймворке или сторонних библиотеках
1.1.2.3. Обработчики данных, парсеры, чекеры, боты
1.1.2.3.1. Эти ребята тоже, как и бизнес-логика, имеют свойство кочевать из проекта в проект
1.1.2.3.2. Обработчики могут зависеть от небольших, нацеленных на конкретное русло, библиотек: HTTP Client, File parser, PDO, PSR
1.2. Глубина нужности фреймворка
1.2.1. Негатив
1.2.1.1. Чем больше фреймворка в коде, тем хуже его поддерживать
1.2.1.2. Компоненты фреймворка обычно покрыты тестами, компоненты проекта не всегда могут таким похвастаться
1.2.1.3. Компоненты фреймворка могут обновляться, меняя свою реализацию
1.2.1.4. Зависимости от фреймворка мешают делать тестирование
1.2.1.5. Нарушается любая архитектура, при утечках зависимостей фреймворка в бизнес-логику
1.3. Рекомендации к написанию кода
1.3.1. Статика
1.3.1.1. Статика почти никогда не нужна. Если и нужна - нужно передумать архитектуру компонента
1.3.1.2. Settings::getSetting приводит любой класс, где он используется, к невозможности покрытием нормальными Unit-тестами
1.3.2. Компоненты
1.3.2.1. Компоненты не должны наследоваться от классов фреймворка. Исключения - компоненты override'ры. Пример: log target'ы
1.3.2.2. Если компонент наследуется от класса фреймворка и содержить бизнес-логику или логику, которая нужна в чистом виде, но в другом месте, то стоит вынести фреймворко-независимую часть в отдельный класс и использовать новый класс в старом (применить рефакторинг "извлечение класса")
1.3.2.3. Компоненты стоит писать так, чтобы можно было их протестировать Unit тестами
1.3.2.3.1. Все зависимости должны приходить в конструкторе или в аргументах методов
1.3.2.3.2. Композиция реализовывается через конструктор или set* методы
1.3.2.3.3. Методы нужные "снаружи" должны быть public. Методы, которые могут быть переопределены при наследовании должны быть protected. Методы, которые никуда не должны попасть должны быть private.
1.3.2.3.4. Если наследников не планируется, то и нечего объявлять методы как protected
1.3.2.3.5. Никаких вызовов фреймворка изнутри компонентов, если они не наследуются от него
1.3.2.4. По возможности стоит избегать реализаций, затрагивающих магические методы
1.3.3. Yii::$app
1.3.3.1. Вне контроллера не используется.
1.3.3.2. Нигде
1.3.3.3. Никогда
1.3.3.4. Вместо этого использовать конструктор и Dependency Injection Container
1.3.4. Формы и сущности AR (+ картинка №2)
1.3.4.1. Форма ни в коем случае не должна зависеть от сущности Active Record
1.3.4.2. Форма наследуется только от \yii\Base\Model
1.3.4.3. Правила валидации сущностей должны валидировать данные перед записью их в БД
1.3.4.4. Правила валидации формы должны покрывать только свойства этой формы, без завязки на внешние формы или Yii::$app->user
1.3.4.5. Правила валидации сущностей и форм не должны содержать сценариев и разделения логики валидации свойств
1.3.4.6. Сущности не должны содержать в себе никаких before/after(Save/Delete)
1.3.5. Работа с сущностями
1.3.5.1. Вся работа должна выглядеть примитивно и описана в одном классе-репозитории
1.3.5.2. Следующим слоем абстракции может выступить класс, реализующий свой use case'у: сейвер формы, сервис по удалению потомков в транзакциях, прочее
1.3.5.3. Одна сущность - один репозиторий
1.3.5.4. Никаких Model::find() в представлениях, формах и контроллерах
1.3.6. Работа с представлениями
1.3.6.1. Никаких вызовов Yii::$app в представлениях