Как и некоторые другие здесь, я вижу только положительные результаты от неопытного пользователя, пытающегося написать фреймворк. Если они рассматривают существующие варианты в качестве моделей и фактически пытаются использовать новый код и, таким образом, идентифицировать его недостатки с целью их исправления, это может стать отличным способом быстрого развития знаний. Тем не менее, для очень нового пользователя, я бы мог подумать дважды об использовании его в производственном приложении; с другой стороны, это, вероятно, не будет иметь большого значения, если основной код приложения будет написан одним и тем же пользователем.
Сказав это, каркас является очень архитектурным по своей природе и, следовательно, возможно, не лучшим местом для начала. Простая библиотека служебного кода намного лучше, и это именно то, что делает OP (без терминологии). Молодец.
Что касается того, чтобы всегда переходить на существующий фреймворк фреймворка, когда приходит время становиться серьезным, у меня есть глубоко укоренившиеся оговорки по этому поводу. Прежде всего, не существует идеальной структуры или даже какой-либо структуры, которая более чем незначительно подходит для любой цели. Большинство сред общего назначения представляют собой чрезмерно сложные ленивцы производительности по сравнению с кодом, настроенным вручную для этой цели. Таким образом, для опытной команды, работающей над сложными, реальными приложениями, платформа GP часто будет плохой идеей. Вот почему, когда дело доходит до таких фреймворков, я предпочитаю такие, как Zend, которые позволят вам выбрать нужную вам функциональность, не запуская обе ноги.
Что более важно, за ~ 30 лет, в течение которых я разрабатывал программное обеспечение, я видел множество фреймворков, даже с почти 100% насыщением рынка и поддержкой основных поставщиков, просто умирающих. Когда это происходит, разработчики оказываются в затруднительном положении. И нет, быть открытым исходным кодом не облегчает эту проблему. Если многим опытным людям требуются годы для разработки, а затем для поддержки большой структуры, как небольшая команда внутри компании - часто с одним или двумя действительно опытными людьми - должна реально поддерживать проект, когда он выходит из строя и начинает умирать? Это также происходит с небольшими проектами: посмотрите на состояние смерти, в котором сейчас находятся многие популярные библиотеки PEAR.