Bjornsen
@Bjornsen
Happy coder

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

Написал недавно по видеоурокам простенький mvc фреймворк на php, вроде суть понял, архитектура действительно хорошо продуманная и наглядная, но вот решил на основе этого фреймворка сделать веб-приложение и впал в ступор по поводу одного вопроса. Суть в том что имеется такая структура папок:
5c24f7ceb87b3707891508.png
Допустим у меня для определенного адреса есть свой контроллер, понятное дело, что размещается он в папке App/Controllers, но что делать, если в логике этого контроллера содержатся инстансы каких-либо вспомогательных классов, то есть где хранить файлы этих классов? Размещать несколько классов в одном файле контроллера не комильфо, мешать файлы вспомогательных классов в папке с контроллерами тоже не выглядит удачным решением. Решил посмотреть как это делается в нормальных проектах, но не нашел в них подобных классов. В общем то я бы мог разместить их где угодно и спокойно использовать, но мой вопрос заключается именно в том, как это принято делать, какие есть best practices в данном вопросе?
  • Вопрос задан
  • 222 просмотра
Решения вопроса 2
SerafimArts
@SerafimArts
Laravel Framework Russian Community
Есть несколько вариантов решения это проблемы.

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/"
        }
    }
}


Таким образом мы запилим совершенно независимый компонент со своими тестами и зависимостями, а внутри основного приложения будем лишь к нему обращаться.
Ответ написан
@magarif
Программист
Я бы в корне создал папку lib или src и там уже по структуре namespace-ов папочки

На эту тему PSR-4 лучше почитать
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
gobananas
@gobananas
botbot.ru
Если работа с БД ведётся то класс в моделях лучше создавать, а назвать его как угодно можно, например Helper
Ответ написан
@dmitriylanets
в вашем случае по типам классов: Helpers, Configs, Exceptions,
Классы которые носят универсальный характер и не связанны с приложением, как правило в /vendor/{your_company}/{project}
как упомянули выше
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы