Yii2 как использовать репозиторий?

Question

[Максим]

Всем привет. Стал потихоньку изучать и внедрять DDD. Вроде бы все понятно, но остался пока один вопрос. У меня есть, например, userServise, в нем подключён репозиторий userRepository и в этом репозитории моя модель user. В репозитории есть методы: save, delete...

Вопрос следующий: как мне свой репозиторий интегрировать с Yii. С моделями User и UserQuery? Чтобы метод репозитория выполнял $user-save(), $user::find() и $user::find()->active()->male()

Answer 1

[Андрей Седышев]

А в чём сложность-то?

class UserRepository {

    public function save(User $user)
    {
        $user->save();
    }

    public function findMale()
    {
        return User::find()->active()->male();
    }
}

Всё, что делает репозиторий - это абстрагирует вас от конкретной реализации получения/сохранения сущности.
Можете сюда хоть голый SQL писать, хоть чтение данных из файла делать.
Главное, чтобы метод возвращал строго то, что нужно.

Comments

[Максим]

Теперь понял) А то везде описано на примерах не завязанных с фреймворком) Правильно ли я понял, что навешивать события в таком случае нужно уже в сервисе, а не модели и тем более репозитории? Или нет...

Ещё вопрос для уточнения. Все таки моделью где работать в сервисе или репозитории? То есть именно применение значений атрибутам... Я понял, что мы это делаем в сервисе. Например установить статус активен...

[Denis]

Модель (АктивРекорд) должна быть максимально пустая (без излишних навесов бихейверов и т. д.)
вся логика переносится в сервис (активация, деактивация, обновления),
Репозиторий содержит только запросы по обращению к бд (достать или сохранить)

Что использовать в сервисе ну в Юии получается что Активрекорд, поскольку его отправляют в шаблон для рендеринга, но по логике DDD конечно это не верно поскольку для неопытного программиста ничего не стоит взять и вызвать у модели метод файнд прямо в контроллере, по-хорошему нужно создавать DTO объекты которые будут возвращать и принимать Репозиторий, но это с не привычки может привести к куче нюансов, путанц и ошибок

[Андрей Седышев]

Максим Ворожцов, давайте так: строго говоря, никто вас не обязывает работать с сущностью (в вашем случае, ActiveRecord-моделью) только в сервисе. Задача сервиса - держать набор сценариев оперирования над сущностью в одном месте. Чтобы методы сервиса вы могли вызвать, условно, из пары (десятков, сотен) других контроллеров и при изменении логики, не пришлось бы менять её во всех этих десятках/сотнях контроллеров.

Моё мнение такое: не рассматривайте парадигму DDD как набор строгих инструкций - это, скорее, просто набор неких принципов.
Если у вашей сущности есть только один/два сценария использования, и маловероятно, что это количество будет расти, стоит ли городить для неё полную обвязку из сервисов и репозиториев?

[Максим]

Denis, хм. А где тогда использовать поведения, если не в модели active record. Избавляться от поведений вообще? Понимаю, что нужно DTO, но пока нет столько времени все это запилить) Можно сказать тогда, мол тогда и пихай все в ActiveRecord. Но так делать не хочется. Хочу следовать solid, пусть даже частично.

[Максим]

Андрей Седышев, Что касается логика, то у меня давно нет логики в контроллере. Она вся в модели AR, но это не правильно. Вот сейчас чтобы активировать пользователя делаю в контроллере $user->activate(); например так. Но сейчас хочу вынести в сервис и репозиторий, пока от AR не могу отказаться совсем.

Вот тоже думаю, что сервис и репозиторий не везде нужен. В моем случае сервис точно нужен, а репозиторий уже думаю. Задумаюсь)

[Denis]

Максим Ворожцов,
Поведения должны максимально простыми (например TimestampBehavior, SluggableBehavior и тд ), которые работают с этой же таблицей, если поведения изменяет другие таблицы или выполняют другие функции не относящиеся к этой таблице (к примеру отправка писем), то лучше это вынести метод сервиса так будет не будет неожиданностей для других разработчиков
ЗЫ
например:
$this->userService->activate($user);
в сервисе у вас будет метод activate(), который вызовет метод репозитория updateByArray($user,['active'=>1])

[Максим]

Denis, да. Поведения максимально работают только с текущей таблицей) Это же облегчает жизнь. Но если повеления убрать будет много копипасы. Особенно если это разные модули, а поведение от фреймворка. Все равно от него зависим. Ну или своё седлать в рамках модуля

[Denis]

Максим Ворожцов,
Я я видел сотни строчек кода когда люди пишут в afterSave, BeforeDelete и т. д. и часто это связано с другими моделями вот таких вещей не должно быть

[Максим]

Denis, ну это да) Бывает такое. Особенно бывает что пихают туда все) Поэтому и нужны поведения и события. Ну или явно указывать в сервисе.

[Андрей Седышев]

Максим Ворожцов, вы решили вопрос? Если да, отметьте решением, пожалуйста.

[Максим]

Андрей Седышев, ой, простите. Почему-то думал что уже давно нажал. Ещё до оставления комментариев нажимал. Видимо сеть пропала...

[Евгений Ромашкан]

Denis, Писать процедурщину в сервисх и анемичные модели тоже "не по DDD"