Какая оптимальная структура хранения кастомных классов в Laravel 11?

Question

[CaptainJustness]

Мне нужно создать кастомный класс для Laravel. Где его хранить лучше? Создать папку App\Services или App\Libraries? Класс взаимодействует со сторонним сайтом через API. Использоваться будет только в Console\Commands

Answer 1

[mrFlyer]

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

Comments

[CaptainJustness]

Да где хотите это не очень вариант. Должна быть хорошая практика, паттерны, общепринятые концепции

[Алексей Уколов]

CaptainJustness, нет таких, каждый пишет как удобно лично ему (или его команде).

[mrFlyer]

Вы заморачиваетесь там, где это не имеет смысла. Если сама лара не заморачивалась с путями моделей даже долгое время. И я вам больше скажу, в 99% случаев никто не узнает где у проекта хранится логика кроме самого разработчика, потому как разработчик будет первый и последний у данного проекта в большинстве случаев.

[CaptainJustness]

mrFlyer, да это понятно. Но хочется для себя сделать как надо. Вот например папку Services задокументирована в Laravel. Там что-то подобное и хранится. Но тогда там еще идет доп подключение через провайдер. Крч что-то усложненный вариант. А если тупо Libraries то это самый простой вариант.

[mrFlyer]

CaptainJustness, ну вот, вы и ответили на свой вопрос =)

[CaptainJustness]

mrFlyer, Да не ответил. Хотелось бы услышать ответ от опытных ребят, которые бы сказали, да такое надо делать в Сервисах, или да такое надо делать в Лайберис, потому что ....

Answer 2

[Adamos]

Ну, раз гуру говорят, что best practices нет, посоветую свою just practice.
Вообще не класть в app ничего сверх того, что там держит фреймворк.
Создать свою папку для своих модулей, внутри них создать свои классы (можно повторить иерархию app).
Вопроса, куда девать то, что в эту иерархию не вписывается, уже не возникает - создаешь папку с названием tools, например, и сваливаешь эти тулзы туда ;)

Такой вариант навеян подходом OctoberCMS, где весь РНР-код разработчика ложится в папку plugins/{developer}/{module}, в принципе не смешиваясь с остальной системой.
Как следствие, в следующий проект этот код переносится куда легче.

Comments

[Владимир Римидалв]

Хм, интересно как оно не смешивается с остальной системой, там код который не используется в контроллерах/DI и код который не использует модели/репозитории?

[Adamos]

Владимир Римидалв, ну естественно, там есть и контроллеры, и модели, просто они лежат по другому пути.
Код в папке vendors, например, распределен аналогично. Вы же не валите все зависимости в app?
В самой папке app нет ничего волшебного, это просто путь, который указан в композере:
"autoload": { "psr-4": { "App\\": "app/" } }
Добавляете туда "MyCompany\\": "mc" - и делаете все свои дела внутри папки mc, которую никакое обновление Laravel, например, не затронет. Хоть вовсе выдергивай эту папку, ставь голую Лару и копируй в нее. Только прописаться в композере... ну, и routes, конечно, для контроллеров.

Answer 3

[Владимир Римидалв]

Учитывая что

Класс взаимодействует со сторонним сайтом через API

я бы предложил создать папку SDK (или API как больше нравится) и в ней создать папку под сторонний проект (app/SDK/ProjectName). Если нужно вынести внутреннюю логику приложения то обычно выносят в Services (Сервисный слой, можно почитать в гугле к вопросу о подходах). Если говорить именно о паттернах, то есть такая штука как Porto, можно про нее почитать, но чаще всего это будет тупо сервисный слой.