Как оформить произвольный класс в Yii2?

Question

[Snewer]

Здравствуйте!

Есть класс, который работает с API стороннего ресурса. Например, загружает изображения. Куда правильней всего, следуя структуре MVC, вынести данный класс? Как его оформить?

p.s. Класс написан своими силами, а не распространяется как composer пакет.

Answer 1

[Decadal]

MVC - архитектура, которая строится при помощи связки модель-вьюха-контроллер. Но это не значит, что любой класс, который вы захотите создать, должен быть либо вьюхой, либо контроллером, либо моделью. Нет, смотрите по назначению вашего класса - в Yii2 существуют хелперы, которые просто созданы в папке helpers (можете создать свою - frontend/helpers, почему бы и нет?). И вызываются примерно так: ArrayHelper::getValue($array, 'foo.bar.name');
Возможно, ваш класс лучше оформить как сервис - тогда почитайте про сервис-локатор. Читайте документацию, смотрите, как работает сам Yii2 и черпайте решения из него же.
Где именно создавать классы? Решайте сами. Если работаете с advanced-шаблоном, можете создать в common папку components и запилить там свои классы. Не забудьте для них указать namespace common\components; и тогда вы сможете подключать их так:

use common\components\MyClassName;
//...
$api = new MyClassName($someConfig);

Comments

[Snewer]

Спасибо за ответ! Да, проблема в "где именно создавать". Класс не вписывается в логику работу компонентов, если сравнивать с теми же User, Session etc. компонентами. Нужно просто создать экземпляр класса, и работать с ним. Запихать его, например в classes с namespace common/classes, конечно, решает проблему, но мне кажется есть более изящное решение в рамках фреймворка.

[Decadal]

Степан Романов
common/widgets - посмотрите, там только класс Alert. Папка для виджетов. Верх изящности. Мы же говорим про внутреннюю структуру проекта, а не про устройство атомного реактора.
я когда-то в Symfony боялся удалить DefaultController. Он был не нужен, вообще никак не использовался - просто разработчики его сделали и он в моих глазах стал неприкасаемым.
Но рамки фреймворка - всё-таки рамки, и не нужно себя в них вгонять, пусть такие вопросы не останавливают разработку. В конце концов, можно провести рефакторинг, когда найдётся решение получше.
Фреймворк - на 40% готовая программа, большая пачка инструментов. Остальные 60% писать вам. Структуру продумывать - тоже.

[Snewer]

Decadal: Спасибо за ответы. Действительно, рефакторинг провести всегда можно, сделаю как захочу пока-что)