От корки до корки, изучать фреймворки

25 Октября 2022 (ред)

Схема фреймворка

Если вы захотите рассказать о своём проекте, о технической его стороне, то, возможно, важным фактом будет указание, на каком фреймворке он написан. Тем не менее самое важное в нём то, какие идеи вы реализовали на этом фреймворке, потому что без них фреймворк способен только на "hello world" и то, пока вы этого не укажете явно.

Примечание. Язык программирования озвучивать не нужно, об этом расскажет сам фреймворк, но все примеры обычно привожу для PHP, так как это даёт мне возможность ввернуть пару слов про свой микрофреймворк на этом языке.

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

Разницы, какой фреймворк выбрать, если это один из более-менее популярных, особо нет. Он будет исправно работать, какой-то медленнее, какой-то быстрее, для реализации идеи — это не так важно. За безопасностью его будут следить, обычно это вполне компетентные программисты, главное вовремя обновлять и сообщать об ошибках, если такие вдруг появятся. Да, показатели могут различаться, но, если этими фреймворками успешно пользуются, значит всё в пределах допустимого.

Схема фреймворка

Большинство узких мест во фреймворках связано с предоставляемой ими ORM, рано или поздно находится очередной редкий пример её использования, когда что-то идёт не так. Особо сложные запросы во избежание ошибок и тормозов пишутся на диалекте SQL, используемом в проекте. То есть... стандартное взаимодействие с базой данных оборачивается толстым слоем ORM и через него, как ни в чем ни бывало, отсылаются классические запросы к базе данных. Может быть, а ORM теоретически не должно быть завязано на конкретной базе данных, это сделает запрос универсальным?

К сожалению, чем больше SQL запросов вы добавляете в проект, не важно через Query Builder, ActiveRecord или Eloquent, каждый из них отдаляет возможность просто взять и переключить тип базы в конфигурации. В смысле - переключить можно, но будет ли также работать, вот вопрос. А уж если есть один или более прямых запросов к базе данных, то без их переписывания точно не обойтись. Поэтому об этом преимуществе стоит забыть. В конце концов, что первым делом делает разработчик, когда запрос в ORM работает некорректно? Он преобразует его в нативный SQL- запрос и смотрит, что не так.

Что касается шаблонизаторов, на официальном сайте cakePHP прямым текстом заявлено, что лучший шаблонизатор на PHP - это сам PHP. Вполне с этим согласен. Знать синтаксис ещё одного почти такого же инструмента намного неудобнее, чем полезная разница между ними. Не только обладать дополнительными знаниями такого типа, но и разграничивать их в уме - добавочная сложность для программиста, потому что применяются они к одной области. И это можно сказать не только про шаблонизатор.

Схема фреймворка

В общем, примеров может быть много, стандартом должен был бы стать Zend Framework, но по части удобства и простоты он сильно проигрывал и сейчас не обновляется, насколько мне известно, остались актуальны только его некоторые компоненты. Можно считать, что удобство - дело привычки и вкуса, но возвращаясь к выводу выше, когда берётся уже распространенная библиотека, например, по работе с консолью из Symfony и потом оборачивается в собственные наименования, как это сделано в Artisan, оставаясь в остальном без изменений, здесь неудобство не только измеримо, но и полностью отрицает практическую заботу о разработчиках, которые будут библиотекой пользоваться.

Схема фреймворка

Так что по большому счёту особой разницы нет, каким фреймворком пользоваться, работать это будет. Ну разве только сложнее будет найти программистов на проект, которые стремятся работать только с хайповыми фреймворками и практически этим задают им курс востребованности, не хуже, как чем у акций на бирже. Но, учитывая, что выбор для большого проекта можно сделать один раз (переход на другой фреймворк слишком затратный процесс), сейчас есть спрос программистов и на старые проекты, когда в моде были Yii2, CodeIgniter, Zend и т.д.

2 Ответа

  1. Evg Evg 26 Октября 2022

    Не так давно читал большие дебаты про Zend Framework на Reddit. Что-то он часто стал в дискуссиях появляться. При чем, встречал тех, кто придерживается ещё 1 ветки: https://github.com/zf1s/zf1

    Конечно его ругают, мол старый, но есть те, кто прям отстаивает его.

  1. fomiash fomiash 26 Октября 2022

    Отстаивают видимо те, кто когда то кодил на нём. Да и сохранилось достаточно много проектов, некогда начатых на ZF. Они и сейчас в строю и проработают много лет ещё, если версию PHP на сервере не обновлять. Несмотря на то, что официальный репозиторий ZF в архиве, кто-то же эти проекты обслуживает.



Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.