Куда выносить логику выборки?

Question

[darksladen]

Подскажите, куда лучше выносить различные проверки для выборки данных? Допустим есть сайт с объявлениями и нужно получить объявления, которые разместил пользователь, а также которыми он воспользовался.. Один из вариантов, при чем самых популярных это 2 строчки в контроллере:

$selling = Ads::where('owner_id', 23);
$purchases = Ads::where('buyer_id', 23);

Но я понимаю, что это плохое решение для более менее сложных проектов, надо куда то такую логику выносить.. В модель выносить такое не хочется.. Сервис для этого делать тоже думаю как то неправильно.. Может в строну доктрина копать? Или этим должны репозитории заниматься? Вообщем подскажите, как лучше это делать..

Comments

[JimmDiGreez]

Репозитории.

Answer 1

[D3lphi]

Вся работа с БД должна производиться в репозиториях.
Репозиторий работает с сущностями, так что, в случае использования active record ORM, из ar модели нужно будет создавать сущность и возвращать ее из репозитория. Не даем подключению к БД "гулять" по проекту. Entity это обычный popo в котором нет какой-либо логики, а есть лишь набор полей, геттеры, ну и методы для обновления состояния.

Например:

class EloquentUserRepository implements UserRepository
{
    public function findBySomething(string $something): ?UserEntity
    {
          $user = User::where('something', $something)->first();

          if ($user !== null) {
              return new UserEntity($user->id, $user->something);
          }

          return null;
    }
}

Может в строну доктрина копать?

Верное решение. Лучше откажитесь от eloquent и возьмите doctrine, если проект требует серьезной ORM.

Comments

[Сергей]

А не подскажите где посмотреть (почитать) про правильную структуру бекенда?

[D3lphi]

Сергей, да, на самом деле, нет какого-то одного источника информации на эту тему, в котором были бы раскрыты детали в достаточной мере.
Читайте Фаулера. Порой, можно подчерпнул что-то из best practices каких-нибудь качественных, правильных (с подходами, близких к академическим) проектов. Та же доктрина, например.
Понимание того, как надо делать, а как - нет приходит с опытом написания "боевого" кода. Это, я считаю, наиболее ценные знания, которыми мало кто делится.

[darksladen]

D3lphi, а в чем самое главное преимущество доктрина не объясните доступно? Я так понимаю в том, что сущности в таком случае будут тупыми и с ними можно поэтому проще работать? Также бизнес логика не будет зависеть от орм.. Поправьте если ошибаюсь

[D3lphi]

darksladen,

Я так понимаю в том, что сущности в таком случае будут тупыми и с ними можно поэтому проще работать?

Да, верно. В случае active record (eloquent) у нас по проекту "гуляет" такой себе god-object, который умеет во все (и к базе запрос сделать, и преобразовать данные, и сохранить их). В случае же data mapper'а (doctrine) сущность используется лишь для представления данных.

Также бизнес логика не будет зависеть от орм..

Верно. Так как всю логику работы с БД мы выносим в репозитории, то при смены ORM нам понадобится лишь написать новую реализацию интерфейсов репозиториев приложения. И все заработает.

Все эти преимущества от использования доктрины очень сильно упрощают поддержку, чтение, тестирование кода.