Alexey
есть
andrew
Воу
andrew
Получается можно как nosql юзать
Good
Итак, флуд пошел, значит можно напрягать снова)))
Делаю модули, в модулях есть внешние зависимости, что логично. Например - модель юзера, которая находится в другом модуле.
Название ее класса передаю как параметр в модуль (через его конфиг), соответственно, в базовом классе модуля производится проверка интерфейса, и есть поле.
В контроллере обращатся к модулю - не зазорно. Но есть модель. В модели есть связь именно на эту внешнюю модель юзера, класс которой передается через конфиг модуля. Можно, конечно, прямо в модели вызывать свойство модуля, я так раньше делал, но это ж вроде как плохо, да?
Теперь передаю этот класс параметром при создании модели. Но! Так не получится, если модель берется через выборку, а не оператором new.
Соответственно, пришлось в ActiveQuery модели переопределить методы all() и one(), и в контроллере передавать туда параметр.
Насколько такой подход будет верным? Я просто пока что лутше не придумал.
Модуль:
https://pastebin.com/D7t53xNk
Модель:
https://pastebin.com/GKG137Dm
Вызов в контроллере:
ActiveQuery:
https://pastebin.com/EgawVSu8
В контроллере вызов:
$firms = Firm::find()->all(['userModel' => $this->module->userModel]);
SiZE
Good
с json уже получилось работать через AR?
Вроде уже можно. если че, можно отключить такое поведение)
Good
Понятно, слишком длинно писать нельзя
Good
Так а как тогда такю зависимость передать?
Good
такую
The Ant
к сожалению я не знаю. Тож долго думал на эту тему. и ниче толкового не придумал
The Ant
решил забить болт и делать как все :)
The Ant
либо, принять тот факт что за пределы фрейма ты свой модуль не выкинешь ) и тогда класть идентити модельку в контейнер под интерфейсом фреймовского идентити
The Ant
уже оттуда дергать ее
Good
А как все делают?)
Good
Не, ну от фрейма отвязатся я и не планирую
The Ant
Можно, конечно, прямо в модели вызывать свойство модуля, я так раньше делал, но это ж вроде как плохо, да? вот так )
Good
И тут ж н только про идентити, а вообще про зависимости
Good
Но перекинуть в другой проект на том же фреймворке - чем плохо?
Good
Кроме того, если минимизировать зависимости, проще вносить изменения потом, проверено уже
The Ant
тем что раскидаешь эти кастыли по всем проектам
The Ant
потом покажется тебе что это херовая идея была, но будет уже поздно :)
Good
Ну я тут вижу костыль только в части передачи параметра в результат выборки, а так прокидывать через сфойство модуля - неплохо, как мне кажется
Good
Вот в выборку - лутше не придумал
The Ant
тут в целом все сложно. даже если ты прокинешь эти зависимости. например в фильтре где-нибудь тебе понадобится список юзеров
The Ant
ии... откуда их дергать? я вот хз
Good
ТОгда делать в интерфейсе метод, который отдает всех юзеров, по другому никак. А в самой модели юзера реализовать интерфейс
Good
В любом случае, так будешь точно значить, що звязи между модулями описаны в интерфейсах четко
Good
И не париться, если меняэться что-нибуть другое
The Ant
http://www.yiiframework.com/doc-2.0/yii-web-identityinterface.html суда клади свою юзер модельку и потом забираешь с контейнера и делаешь чо нада
The Ant
вот как делать связи... ваще вопрос )
Good
Ну вот, так и много их
The Ant
был бы инжект через метод.. можно было бы что-то типа:
public function getAdministrators(\yii\web\IdentityInterface $user)
{
return $this->hasMany($user::class, ['id' => 'user_id'])
->viaTable('{{%std_firms_administrators}}', ['firm_id' => 'id']);
}
м.б. через рефлексию или как
The Ant
или попробовать через конструктор закинуть... бля )
The Ant
но как это скажется на производительности...
Good
Ну в моїм случае, производительность самого пхп - последнее, г чем нужно парится)
The Ant
в твоем случае нет интерфейсов
Good
Есть
Good
Если захочу
The Ant
без них смысла нет эти зависимости прокидывать
Good
Пока что не нужно для юзера, но если будет еще что-то, то буду писать свои
Good
По-сути, сейчас интерфейсы вот:
DependenciesCheckHelper::checkClassHasParent($this->userModel, '\yii\db\ActiveRecord');
DependenciesCheckHelper::checkClassImplementsInterface($this->userModel, '\yii\web\IdentityInterface');
Good
То есть, класс юзера должен быть потомком ЕктивРекорд и реализовывать АйдентитиИнтерфейс
Good
Если есть что-то еще, тогда нужно уже свой писать для каждой зависимости, да это не сложно, вобщем
The Ant
все не то
The Ant
хэлперы эти
The Ant
лишние )
Good
Ну а как проверять интерфейс?
Good
Это мой хелпер, просто чтоб не пихать всюду один и тот же код
The Ant
не знаю )
The Ant
оно все как-то очень и очень печально выглядит
(;￢＿￢)
посоны, там codeception поломали с 2.4.0
Good
Ну так и проверяю. просто в хелпере реализована возможность проверять сразу несколько, и. т. д.
The Ant
я вообще не вижу нормальных вариантов )
Good
Ну вот. поэтому так делаю) Я ж по всякому пробовал
Good
Тут же даже не по фреймворку вопрос, а в целом. Как-то же прокидываются зависимости
Good
Со всех способов вариант с интерфейсами кажется самым нормальным
Good
Классы передавать в свойства модуля, в модуле проверять на интерфейсы и другие ограничения, а там уже использовать, как хочется
who are you
какая примерно зарплата в питере у прогера делающего лендинги, html верстку стили свой дизайн согласно заданию?
The Ant
по нормальному нада внедрять зависимости через контейнер, а не через свойства модуля )
The Ant
и тут вот очко полное
Good
по нормальному нада внедрять зависимости через контейнер, а не через свойства модуля )
Ну так я понимаю, внедрение через конфиг - это частный вариант внедрения через контейнер
Good
И через контейнер все равно в свойства записывают, разве нет?
The Ant
ну если там лежит что-то под интерфейсом, ты можешь быть уверен что оно реализовано
Good
Или имеется ввиду прямо в главном классе модуля делать внедрение в класс модели?
Good
Кстати, вариант. Я че-то не подумал
The Ant
а в твоем случае где гарантия, что есть метод какойнить типа: getOnlyEnabledUsers()
Good
ну если там лежит что-то под интерфейсом, ты можешь быть уверен что оно реализовано
Да. но нужно же проверить, реализует ли класс интерфейс
Good
а в твоем случае где гарантия, что есть метод какойнить типа: getOnlyEnabledUsers()
Ну вот для этого и проверяется интерфейс, в котором он записан
The Ant
Да. но нужно же проверить, реализует ли класс интерфейс
уишный контейнер не положит что попало под интерфейс
The Ant
только то что имплементит его
Good
Честно-говоря, плаваю в нем еще)
Good
как мне, допустим, заинжектить название класса юзера в класс модели фирмы в модуле, чтоб срау проверять интерфейс?
Good
Я не совсем понимаю механизм
The Ant
в том то и проблема что никак )
The Ant
то, что будет под интерфейсом, вернется объектом уже
Good
Ну можна просто сначала проверить имплементацию интерфейса, и тогда инжектить
The Ant
допустим положим класс в контейнер:
Yii::$container->set('psr\log\LoggerInterface', \monolog\Logger::class):
а заберем уже объект:
Yii::$container->get('psr\log\LoggerInterface');