Для успешной разработки программного обеспечения важны разумное ограничение затрат времени и выбор способов решения задачи. Как я обнаружил, в PHP-фреймворках много такого, что нужно не во всех приложениях. Из-за этого вес пакета и число файлов, упоминаемых в одном логе становится неудобно большим. При этом, число пакетов, используемых под капотом при выполнении базовых действий невелико.

В какой-то момент я понял, что моё дальнейшее развитие как разработчика требует уменьшения затрат времени на треть. Поисковик, генерирующий ответ, увеличивает её не более чем на четверть, и то в основном за счёт чтения документации. Логично взять и соединить всё лучшее от современных технологий и подходов, проверенных временем. Быстро обнаружил, что регулярно не укладываюсь по времени на целые проценты нужного срока. Само собой разумеется проанализировал то, что мешает писать качественный код быстрее. Обнаружил, что фреймворк вообще и реализации отдельных паттернов проектирования в частности, загромождены. Не все очень длинные классы имеют одну ответственность. Нередко в одной сущности объединена функциональность, нужная по отдельности и занимающая много места в коде и в уме.

Сразу замечу, что писать длинные классы не всегда неприемлемо. В любом принципе помимо общего правила есть исключения. Класс с одной ответственностью может содержать большое количество строк кода. Вот только должен поддерживать быструю настройку описанной в нём функциональности. Качественно другая функциональность должна добавляться не путём изменения существующей, а путём создания отдельного модуля. Быстрота понимания разработчиком сложной логики гарантирует выявление подходящего способа решения задачи за разумный срок. Поэтому, я решил написать новый фреймворк с минимальной необходимой функциональностью.

Цель разработки фреймворка - разумно ограничить времяёмкость разработки на PHP. Для её достижения нужно по возможности избежать загромождения, дублирования PHP и повторного написания кода. Чтобы избежать загромождения, взял за правило не использовать ничего кроме чистого PHP без необходимости. Чтобы использовать все возможности PHP переходил на новую версию, в случае её выхода. Так как я не раз переписывал отдельные модули, код в основном написан на PHP 8.5. Чтобы не изобретать велосипед, предусмотрел интеграцию пакетов, отвечающих за безопасность ввода и вывода данных. Интегрировал только самые распространённые пакеты: laravel/database, doctrine/mongodb-odm, twig/twig и guzzlehttp/guzzle.

Средство достижения цели - научное распределение ответственности между классами. Запрос должен обрабатываться небольшим количеством классов. Ответственность класса должна быть очевидна. Имени класса, рассматриваемого в контексте слоя приложения, в котором он находится, должно быть достаточно, чтобы понять, за что он отвечает. Место сущности в системе должно соответствовать устоявшимся подходам к распределению ответственности и наименованию классов. Поэтому, я взял за основу архитектуры фреймворка паттерн MVC и шаблоны GRASP.

Название фреймворка Simpledynamic. Это переводится, как простая движущая сила. Simple - простой. В том числе применительно ко времени глагола. Dynamic - действующий. А именно рассматривающий воздействующий силу, как причину движения. По сути это быстрый PHP-фреймворк. Быстрый потому, что современный и лёгкий. Быстрый, то есть заточенный под ускорение разработки путём проектирования и обдуманной настройки.

Простая автоматизация процессов не настолько сильно ускоряет разработку, как можно подумать. Опыт показывает, что скорость разработки зависит от читаемости кода. Во время разработки Simpledynamic я уделил повышенное внимание читаемости кода и чистоте архитектуры. Архитектурные концепции взяты из популярных фреймворков и привычны разработчику. Особенностью Simpledynamic является система базовых сущностей.

Модель Simpledynamic разделена на три части. Собственно модель - результат запроса, содержащий необходимую информацию. Билдер - создатель запроса, использующий интегрированный пакет. Репозиторий - исполнитель запроса, использующий билдер и создающий модель. С одной стороны в контроллер возвращается модель, а не DTO. С другой стороны между контроллером и слоем, использующим интегрированный пакет, есть промежуточный слой.

Представление Simpledynamic имеет сложное воплощение в коде. Собственно представление - макет ответа, написанный по шаблону из интегрированного пакета. Клиент - отправитель ответа, по сути интеграция пакета, отправляющего запросы. Парсер - преобразователь, позволяющий работать с определённым форматом ответа. Далеко не каждое представление включает все три сущности. Независимость структуры ответа сочетается с полиморфностью вариантов ответа.

Контроллер Simpledynamic включает вынесенные вспомогательные элементы. Собственно контроллер - обработчик, использующий методы исполнителя запроса. Роут - получатель, то есть класс, в котором инкапсулирована логика получения запроса. Мидлвар - посредник, передающий данные от получателя к обработчику. Для логики, которая должна быть в контроллере, выделяется специальный тонкий слой. В то же время, вынесенные вспомогательные элементы позволяют контролировать воздействие на программу извне.

Стержнем, на котором держится система базовых сущностей и весь Simpledynamic, является отношение разработчика к языку программирования. Приоритетными являются решения, основанные на возможностях PHP. Я не переношу что-либо с уровня языка на уровень фреймворка без веских оснований. Безусловно к веским основаниям относятся соображения безопасности. Взаимодействие с другими программами осуществляется главным образом через интегрированные пакеты. Интеграцию популярного пакета не сложно заменить на интеграцию другого пакета. Simpledynamic наглядно демонстрирует не только результат использования, но и силу языка.

Фреймворк Simpledynamic выложен на GitHub в виде трёх пакетов. Установщик скачивает шаблон приложения, который в свою очередь имеет в зависимостях фреймворк.
Фреймворк https://github.com/sergei-tsel/simpledynamic
Установщик фреймворка https://github.com/sergei-tsel/simpledynamic-installer
Шаблон приложения на фреймворке https://github.com/sergei-tsel/simpledynamic-tablemap

Комментарии (2)


  1. japanxt
    05.07.2026 10:18

    Непонятно зачем это использовать, проще просто эти же библиотеки использовать, но без участия этой поделки.


  1. PAL_habr
    05.07.2026 10:18

    Что бы такое написать, чтобы человек правильно писал слово "чтобы"?.. ;)