Просто твой подход передает овнера во всюда, по сути где нужен или нет.
У тебя идет одно и важных нарушений архитектуры ( Low Coupling ) Низкой связанности,
У тебя получатся не отделить какой-то компонент и не получиться использовать их отдельно, примеры именно низкой связанности это Симфони и Зенд, когда ты можешь просто взять например Zend_Mail и использовать его отдельно, или HttpFoundation отдельно от Симфони
У тебя как раз таки проблемма Yii когда ты ничего отдельно от Yii не сможешь использовать, и у тебя получается полная завязанность на Core::c

А вот сильное сцепление, у тебя должно быть внутри пакета, допусти возьмем например Gear\Db из головы, у тебя туда относиться и Connection и Adapter\Mysql или прочие, и DAO для запросов притом они работают так что например
Построитель запросов использует коннект для отправки в него запросов, но он его никоим образом сам не генерирует и не склеивает, он его должен был получить через интерфейс, тогда у тебя будет простота и взаимозаменяемость


Один компонент может работать с другимЮ для этого есть интерфейсы, и тогда например отдельные классы Repository или DataStorage смогут использовать их для работы с бд, или например api vk ( это как раз уже переход к проектированию по модели, DDD )

и твоё $this->getConnection()->save($user->props()) будет где-то внутри

$container->get('UserRepository')->save($user);

но это пиздец такая тема замудреная, разделение бизнес-логики от инфраструктуры, и отделение мух от котлет))

bestxp

Michael
bestxp
Понятно, запишу в issue.

_____________
Gear Framework
Gear Framework на Github

bestxp
Думаю, что балансом должен озаботиться программер. А возможность отключать - само собой.

_____________
Gear Framework
Gear Framework на Github

Вот закончил реализацию генератора кода. Пока он может только разворачивать новые проекты, т.е. по команде создавать папочки под новый проекты, и все нужные файлики. Конфигурирование в файлике gear/builder/builder.app.manifest, пример использования

$ php builder.php -e application --name helloWorld

_____________
Gear Framework
Gear Framework на Github

1. Как уже писали выше нужен Composer(избавьтесь от nih синдрома, начните применять сторонние библиотеки).
2. Соответствие стандарту PSR-0, PSR-2
3. Статические методы вы применяете не рационально, проще сказать не оправдано.
4. Фреймворк выглядит как неполноценный Yii, я плотно не работал с Yii, но видел его код и конфигурационные файлы, у вас все это очень похоже выглядит.
5. Ваш фреймворк не выделяется, непонятная идеология (свои термины, я это про процессы), отсутствие RAD, отсутствие гибкости и другие не реализованные вещи.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

chee
1. Я буду думать над этим, но чуть позже.
2. PSR-0, PSR-4 вроде соответствует.
3. Статические методы имеют только ядро и те элементы (модули, компоненты, плагины), классы которых поддаются конфигурированию. Больше статика нигде не используется. Но я не просто завёл эту тему, поэтому если не сложно, то прошу указать в чём и где выражается "не рационально... не оправдано".
4. Повторюсь, что этот свой фреймворк я пытаюсь реализовать уже года три, с Yii я знаком ровно год (можно годовщину, кстати, справить ), поэтому любые совпадения абсолютно случайны.
5. Да, а всё потому, что я не писатель и не пиарщик, но я попробую:

- Свои термины: процесс - он что-то делает с помощью своих методов, т.е. своего api. Понятие контроллера в этом контексте выглядит идиотическим, но кто-то придумал такое именование и все привыкли, ну и ладно. Симфони придумал какие-то бандлы, ну и ладно, кто запрещает. Хелперы и прочее, а проще библиотеки функций/методов. У меня: приложение - как рабочая среда, процесс - это процесс, который в этой среде что-то делает полезное по запросу, процесс делает что-то полезное через свои методы, которые называются api-методами потому, потому что доступны для внешних пользовательских запросов. Нацел на web-services.
- Я не фанат MVC, но насколько я понял моя архитектура попадает под HMVC. Не берусь это утверждать, но очень похоже.
- Моя идеология:
a) Модульность, в системе, кроме ядра, можно менять всё на своё и усмотрение и потребности. Не нравится автозагрузчик - меняем на своё, не нравятся обработчики исключений и ошибок - меняем, не нравится роутинг стандартным менеджером процессов - меняем, и т.д. и т.п.
б) Нарисуй себя сам, любой объект в системе может сам себя "отрисовать" через соответствующий плагин, достаточно указать шаблон.
в) Межпроектное взаимодействие, если несколько проектов крутятся на одном серваке, то они могу использовать код друг у друга без копипаста, правда при условиях, что этот код не имеет жёстких связей непосредственно с классом приложения.
г) Гибкость при использовании баз данных (ни один DbConnection не привязан к какой-либо базе данных, т.е. выбор баз данных делается не на уровне коннекта к MySQL-серверу, а грубо говоря моделью), абстракция с noSQL, т.е. в общих случаях разницы между запросом к MySQL и MongoDB быть не должно, а сами запросы строятся по принципу MongoDB: selectDB(), selectCollection(), find(), findOne(), sort() и т.д. Сюда же я хочу прикрутить абстракцию к key-value хранилищам Redis, Memcached и т.п.
- Конфигурация да похожа, но это по-моему единственно быстрый и удобный вариант. В моём случае из коробки доступны некоторые плюшки связанные с неймспейсами и относительными путями, плюс разносить по файлам можно конфигурации модулей, компонентов, плагинов.
- Не знаю, существует ли сейчас в Yii, но у меня api-метод процесса может быть анонимной функцией, параметры которой заполняются из значений параметров соответствующего POST/GET-запроса. Собственно и процесс может быть анонимной функцией (но тут ещё кое-что допилить надоть будет).