Где размещать вспомогательные классы в mvc архитектуре?

Question

[John Bjornsen]

Написал недавно по видеоурокам простенький mvc фреймворк на php, вроде суть понял, архитектура действительно хорошо продуманная и наглядная, но вот решил на основе этого фреймворка сделать веб-приложение и впал в ступор по поводу одного вопроса. Суть в том что имеется такая структура папок:

Допустим у меня для определенного адреса есть свой контроллер, понятное дело, что размещается он в папке App/Controllers, но что делать, если в логике этого контроллера содержатся инстансы каких-либо вспомогательных классов, то есть где хранить файлы этих классов? Размещать несколько классов в одном файле контроллера не комильфо, мешать файлы вспомогательных классов в папке с контроллерами тоже не выглядит удачным решением. Решил посмотреть как это делается в нормальных проектах, но не нашел в них подобных классов. В общем то я бы мог разместить их где угодно и спокойно использовать, но мой вопрос заключается именно в том, как это принято делать, какие есть best practices в данном вопросе?

Comments

[ThunderCat]

каких-либо вспомогательных классов,

это каких?

как это делается в нормальных проектах, но не нашел в них подобных классов.

может они просто не нужны, или вы что-то не так делаете? Что хотите сделать то?

[John Bjornsen]

ThunderCat, ну если у меня есть допустим какие-то сущности, например, из реального мира, которые описаны классами и в контроллере я оперирую объектами этих классов. Конкретно в моем случае возможно классы и не нужны, я их завел для наглядности и удобства компоновки некоторых данных. У меня имеется класс Поликлиника, у которого есть несколько полей и пара методов и массив этих объектов является полем другого класса - Регион, у которого так же есть несколько полей. Мне показалось, что так будет лучше, чем в голых массивах все хранить.

[ThunderCat]

John Bjornsen, это стандартные модели, то что они не классические как item или db не должно вас смущать. В моделях пусть лежат.

[John Bjornsen]

ThunderCat, а это не создаст мешанину в папке Models, по мере того как кол-во таких "вспомогательных" классов будет расти? Или стоит в папке с моделями создать подпапку?

[ThunderCat]

John Bjornsen, если хотите прям по современным канонам - читайте PSR4 и раскидывайте по соответствующим неймспейсам. Я вот в большинстве проектов складываю модели в model. Обычно набирается 25-35 моделей для крупного проекта, имхо не много для одной папки.

[John Bjornsen]

ThunderCat, ясно, спасибо

Answer 1

[Кирилл Несмеянов]

Есть несколько вариантов решения это проблемы.

1) Некоторые могут пропагандировать сервисный слой (design-pattern.ru/patterns/service-layer.html), как следствие: "App/Services/ServiceName" - набор классов, отвечающих за какое-то абстрактное действие. Например: "UserAvatarUploaderService", который отвечает за загрузку аватарки пользователя.

2) В качестве альтернативы и способ, который предпочитаю я - это создание директории "src" с набором независимых компонентов, включая собственный composer.json. Тот же сервис загрузки аватарки будет выглядеть следующим образом:

- src/
    - AvatarUploader/
        - README.md
        - composer.json
        - tests/ ...
        - src/
            - AvatarInterface.php
            - FileSystemInterface.php
            - FileSystemUploader.php
            - UploaderInterface.php

Для подключения этой библиотеки достаточно будет прописать в корневом:

{
    "repositories": [
        {
            "type": "path",
            "url": "./src/AvatarUploader"
        }
    ],
    "require": {
        "app/avatar-uploader": "*"
    }
}

А выглядеть внутренний (т.е. внутри "src/AvatarUploader") composer будет так:

{
    "name": "app/avatar-uploader",
    "autoload": {
        "psr-4": {
            "AvatarUploader\\": "src/"
        }
    }
}

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

Comments

[John Bjornsen]

Интересное решение, спасибо!

Answer 2

[Марат Гарифуллин]

Я бы в корне создал папку lib или src и там уже по структуре namespace-ов папочки

На эту тему PSR-4 лучше почитать

Comments

[John Bjornsen]

то есть если взять мой случай, то в папке libs/App/Controllers хранились бы вспомогательные классы, используемые в контроллерах, а в libs/App/Models те, что используются в каких либо моделях, как то так?

[Марат Гарифуллин]

John Bjornsen, Не совсем

Например класс со вспомогательными функциями
\MyProject\Helpers\Helper
лежит в
/src/Helpers/Helper.php

Для работы с изображениями
\MyProject\Helpers\Image
лежит в
/src/Helpers/Image.php

Для работы с СоцСетями
\MyProject\SocServ\Base
лежит в
/src/SocServ/Base.php

конкретно для VK
\MyProject\SocServ\Vk
лежит в
/src/SocServ/Vk.php

[John Bjornsen]

magarif, оу, понял, спасибо

[Марат Гарифуллин]

John Bjornsen, Но у вас должен стоять Autoloader соответствующий PSR-4
https://www.php-fig.org/psr/psr-4/

И подключить свои классы примерно так (зависит от загрузчика)

// instantiate the loader
$loader = new \Example\Psr4AutoloaderClass;

// register the autoloader
$loader->register();

// register the base directories for the namespace prefix
$loader->addNamespace('MyProject', '/src');

[John Bjornsen]

magarif, да, спасибо, это я знаю, в своем проекте я использую загрузчик композера

Answer 3

[Adamos]

/vendor/{your_company}/{project}?

Answer 4

[Дмитрий Дарт]

Если работа с БД ведётся то класс в моделях лучше создавать, а назвать его как угодно можно, например Helper

Comments

[John Bjornsen]

Классы такие (лично у меня в проекте) это представления сущностей из реального мира, по сути можно было бы обойтись и без них, но с ними нагляднее. А по поводу моделей, я просто подумал, не создаст ли размещение подобных классов в папке с моделями кашу? Вроде как некрасиво получится.

[Дмитрий Дарт]

John Bjornsen,

представления сущностей из реального мира

когда-то я тоже смотрел туториалы

Answer 5

[dmitriy]

в вашем случае по типам классов: Helpers, Configs, Exceptions,
Классы которые носят универсальный характер и не связанны с приложением, как правило в /vendor/{your_company}/{project}
как упомянули выше

Answer 6

[Takasu]

Папка system, lib, любое_имя в корне