Как правильно выносить логику из моделей?

Question

[Денис]

Сейчас у меня основная логика работы с бд вынесена в сервисы. Они дёргают модели и что-то делают. Но по факту все методы в сервисах статические т.к. не хранят ничего вообще. По сути просто набор функций отвечающий за ту или иную модель. Ну и так если задуматься то разницы между самой моделью в общем-то и нет. Можно конечно в сервисе хранить экземпляр модели, но разницы нет что Auth::user() что $this->getUser(); даже хуже. Как правильнее будет сделать? Бизнес логики никакой нет, по факту только CRUD с моделями. Оставить всё в моделях и дёргать прямо из контроллера их методы? Проект простой, никаких абстракций, сущностей пожалуйста не предлагайте :) сыт репозиториями бесполезными.

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

Comments

[Sanes]

Модели для того и придуманы, чтобы работать с базой.

Answer 1

[jazzus]

Есть ли способ код в модели раскидать по разным классам сгруппировав по общему смыслу но чтобы они были все одной моделью?

Трейты.

но разницы нет что Auth::user() что $this->getUser();

разница есть. В первом случае я понимаю что получу авторизованного юзера. Во втором получу какого-то юзера непонятного. А если открою метод и увижу Auth::user() будет фейспалм)

сыт репозиториями бесполезными

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

Comments

[Денис]

Но я же вроде не смогу обращаться к свойствам модели из трейта? Выходит придется в параметры выносить объект модели?

[jazzus]

Денис, можешь. Доступ из трейта через $this

[jazzus]

Денис, можешь 1 трейт к нескольким моделям подключиь написать там $this morphMany comments и потом вызывать у любой модели $model->comments

[Денис]

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

[jazzus]

Денис, я бы подсказал, но навыками телепатизма не обладаю) Auth::user использовать в моделях звучит как плохая идея. Лучше передавать в метод User $user. К другим моделям обычно обращаюсь через связи

[Денис]

Просто я на 100% уверен что $user всегда и везде будет один и тот же - текущий из бд :) Можно ли как-то попросить у тебя небольшое ревью кода проекта? Могу оплатить. Проект небольшой, где-то 7-8 моделей, 15-20 роутов, 60 тестов.

[jazzus]

Денис, я только на Тостере пишу. На другое времени нет. Судя по вопросам лучше пока ничего никуда не выносить и писать простыней в контроллерах и моделях) Выносить нужно точно в классы Ларавел - реквесты, ресурсы, политики, обсерверы, а другое уже потом по необходимости. А не просто так потому что где-то об этом написали.

[Денис]

jazzus, понял, спасибо)

Answer 2

[Илья Чубаров]

Во-перых репозитории не бесполезны.
Во-вторых все что придумали или придумывают имеет смысл, но не везде и не всегда.

Если у ваc простое CRUD приложение, зачем вам нужны сервисы?
Скорее всего вы хотели разгрузить контроллеры и фактически перенесли просто код из одного местов в другое.
И какой код может быть общий, если это просто CRUD.
В Eloquent уже есть вся магия для создание crud

User::create()
User::update()
User::find()

Если у вас что-то больше, до значит какая то бизнес - логика все же есть.
Я вижу два пути:
- Это читать статьи и книги по архитектуре, подойдет Фаулер, Эванс Эрик, Вернон Вон..Раз вас тянет туда по можете параллельно этим заниматься
- Просто писать дальше в духе Laravel, но первое второму не мешает.
Для начала еще эту прочитать.
Если все прочтете много раз, вопросов станет еще больше, дерзайте!

Comments

[Денис]

спасибо за подробный ответ :) Да, логика есть, но в основном всё же почти полностью связана с базами данных. Если так, то изменить так, если иначе, то вообще удалить и тд. Да, фактически действительно сервисы лишь чтобы перенести логику в другое место. Действительно, в сервисах редко один метод используется больше одного раза. Но хорошая ли это практика? Всё же в одном контроллере могут использоваться несколько методов сервиса, для меня это облегчает чтение своего же кода.

[Илья Чубаров]

Зависит от целей:
Для себя лично вы можете делать что угодно особенно если больше никто и никогда не будет работать с этим годом.
Тут нет универсального ответа, но выносить код из одного места в другой для улучшения чтение - смысла мало.
Есть смысл - выносить код в другие места для уменьшение ответственности каждого класса и сведения этих ответственностей к всего лишь одной.
Почитаете книгу по ссылке и SOLID она вам даст толчок для развития.
К списку авторитетных авторов могу еще добавить Роберта Мартина.

Answer 3

[dmitriy]

Я использую CommandBus и Command для организации бизнес логики, изменения состояния сущностей, в Сервисах если и остаётся то только на получение данных

Comments

[Денис]

Почитал в интернете. Выглядит красиво, хоть и не до конца понимаю всё. На каждый экшен контроллера создаётся своя команда?

[dmitriy]

примерно да, например регистрация клиента
мы можем создать команду которая зарегистрирует клиента и сформирует событие или вызовет другие команды
$this->commandBus(new ClientRegistrationCommand($clientData,$shop))
соответственно создаем контроллер для Rest API

public function register(): JsonResponse{
    $clientData = $this->createDataFromRequest();
     ...
    $this->commandBus(new ClientRegistrationCommand($clientData,$shop))

    return new JsonResponse([
      'result' => 'success'
    ]);
}

но можем использовать например в обработчике формы

public function formSubmit(array $data): string{
    $clientData = $this->createClientDataFromArray($data);
     ...
    $this->commandBus(new ClientRegistrationCommand($clientData,$shop))
    return 'Регистрация успешно завершена';
}