Интересный подход к синтаксису. Жаль or и and без подчёркивания использовать не получится. Путаница неизбежна. Даже в примерах автор путается и пишет без подчёркивания.
Что значит не завели функциональные тесты? Отлично работают.
По поводу брейкпоинтов, да, остановится на нём так и так. Вот только найти куда его поставить становится довольно сложно и проследить, куда далее пойдёт по коду в случае сильного использования DI-контейнера тоже непросто, даже в типизированных языках вроде Java.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
1) Низкая связанность хоть и хорошая штука в общем, но сильно портит API во многих случаях. В Yii она просто не нужна. Оттестировать мы можем любой код.
2) При использовании DI и контейнера в особенности возникают как минимум вот эти побочки:
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Ну и получаем мы с этого не так много: тестировать слабо связанный код немного проще, но не так чтобы уж слишком. Ну и если программист захочет использовать объект, он его либо вытащит из репозитория, либо инъектнет, либо протащит через конфиг контейнера. Кроме самодисциплины и ревью тут ничем не помочь.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно. Использовать что-то совсем иное немного проблемно, да. Но на это есть причина. Внешние пакеты. Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер. В проект вытянется очень много разных мейлеров и все их придётся поддерживать, слать в них одни и те же баги и т.д.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
1. AR и не предназначен для использования отдельно. Ни один компонент Yii не затачивается под это.
2. По мне так многоуровневая инъекция превращает код в нечитаемый и трудноотлаживаемый слоёный пирог.
3. Они уже почти полностью покрыты тестами.
4. На вкус и цвет. У меня привычка с Java, там они все в нижнем регистре и всё нормально.
Тут у нас получается два одноимённых класса. PHP не позволяет использовать их без задания алиаса аля use \yii\base\Controller as BaseController;. Чтобы народ не путать названием BaseController, сделано без алиаса.
SET NAMES utf8и отсутствие экранирования таблиц.orиandбез подчёркивания использовать не получится. Путаница неизбежна. Даже в примерах автор путается и пишет без подчёркивания.CodeCeption в 1.1 официально не поддерживается. В 2.0 точно работать будет.
По поводу брейкпоинтов, да, остановится на нём так и так. Вот только найти куда его поставить становится довольно сложно и проследить, куда далее пойдёт по коду в случае сильного использования DI-контейнера тоже непросто, даже в типизированных языках вроде Java.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
2) При использовании DI и контейнера в особенности возникают как минимум вот эти побочки:
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Ну и получаем мы с этого не так много: тестировать слабо связанный код немного проще, но не так чтобы уж слишком. Ну и если программист захочет использовать объект, он его либо вытащит из репозитория, либо инъектнет, либо протащит через конфиг контейнера. Кроме самодисциплины и ревью тут ничем не помочь.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно. Использовать что-то совсем иное немного проблемно, да. Но на это есть причина. Внешние пакеты. Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер. В проект вытянется очень много разных мейлеров и все их придётся поддерживать, слать в них одни и те же баги и т.д.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
1. Хелперы не наследуются от Object. В массиве свойства объектов по умолчанию.
2. По мне так многоуровневая инъекция превращает код в нечитаемый и трудноотлаживаемый слоёный пирог.
3. Они уже почти полностью покрыты тестами.
4. На вкус и цвет. У меня привычка с Java, там они все в нижнем регистре и всё нормально.
use \yii\base\Controller as BaseController;. Чтобы народ не путать названием BaseController, сделано без алиаса.