Laravel как создать связь через несколько таблиц?

Question

[Yariy]

Суть такая, есть таблица пользователей и таблица филиалов. Связь много-ко-многим (belongsToMany)

Есть таблица Склад, она относится к филиалу, как много-к-одному (belongsTo)
И есть таблица Тарифы, она относится к складу, как много-к-одному (belongsTo)

Филиалы, к которым привязан пользователь, я могу получить как
Auth::user()->branches()->get()
А как мне получить склады, которые относятся к филиалам, к которым есть доступ у пользователя?
И еще заковыристей: как получить тарифы, которые относятся к складам, которые относятся к филиалам, к которым есть доступ у пользователя?

Comments

[Корбен Даллас]

Из коробки - Никак.

Не из коробки - есть такой класс Relation, от него унаследованы все BelongsTo, И так далее

Реализуйте новый класс рилейшена и выстроите цепочку через несколько таблиц, а еще лучше в гитхаб сразу и собирайте звезды. Думаю всем пригодится. Если такой рилейшн будет поддерживать eagerLoading, и будет работать через with

[Yariy]

Корбен Даллас, ох, я бы с радостью, но с ларой у меня стаж работы от силы месяц =(

[Корбен Даллас]

Yariy, тогда может вам нет смысла такой рилейшен пилить встроенными средствами.

Вам для чего надо?
Точнее сделайте репозиторий типа такого:

interface RepositoryInterface
{
    public function save(Model $model): void;
    public function delete(Model $model): void;
}

trait RepositoryTrait
{
    abstract protected function getModel(): Eloquent\Model;

    private function getQuery(): Eloquent\Builder
    {
        return $this->getModel()->getQuery();
    }

    public function save(Model $model): void
    {
         $model->save();
    }

    public function delete(Model $model): void
    {
         $model->delete();
    }
}


class Warehouse implements RepositoryInterface
{
       use RepositoryTrait;

       public function getByUser(User $user): Eloquent\Collection
       {
           return $this
               ->getQuery()
               ->leftJoin(филиалы...)
               ->leftJoin(пользователи...)
               ->where(пользователь = $user)
               ->get();
       }

       protected function getModel(): Eloquent\Model
       {
          return App::make(Warehouse::class);
       }
}

И тд наделайте под каждую сущность репозитории и получайте свои связи через кастомные квери

Ведь в конечном итоге вам нужны ведь данные чтобы их где то отобразить?

[jazzus]

Корбен Даллас, а будет еще где-нибудь метод save над этим методом save? Так чтобы наверняка сохранилось) getModel это вообще шедевр

[Корбен Даллас]

Это просто пример, как организовать работу через репозитории, из удобно подключать через DI в сервисах, контроллерах и тд

Использовать это можно, если вы не хотите создавать новые слои например так

Контроллер

...
   public function store(Request $request)
   {
        $this->dispatchNow(
            new CreateWarehouseCommand(
                $request->user(),
                $request->validated()
            )
        );
    }
    ...

Команда

class CreateWareHouseCommand
{
    private User $user;
    private array $data;

    public function __construct($user, $data)
    {
        $this->user = $user;
        $this->data = $data;
    }

    public function handle(WarehouseService $service)
    {
         DB::transaction(function () use ($service) {
             $service->create($this->user, $this->data);
             // если надо создать что то еще можно вызывать другие сервисы
         });
    }
}

Сервис

class WarehouseService
{
    private $repository;

    public function __construct(WarehouseRepository $repository)
    {
         $this->repository = $repository;
    }

    public function create(User $user, array $data): void
    {
         $model = $this->newModel();
         $model->fill($data);
         $model->author()->associate($user);

         $this->repository->save($model);
    }

    private function newModel(): Warehouse
    {
        return App::make(Warehouse::class);
    }

    ...
    
    // update, delete, ....
}

Это просто организация слоев для того, чтобы было удобнее разграничивать ответственность каждого компонента.

Выделяя работу с БД в репозитории вы сможете в тестах замокать и протестировать юнитами всю бизнес-логику.

Командный слой позволяет обеспечивать транзакционность сложных дествий, например когда вместе с созданием склада создается еще чтотто например филиалы и сотруники к нему.

Одно без другого не может быть поэтому либо создается все либо ничего.

В дальнейшем в команду можно добавить обращение к слою бизнес валидации и тд

[Корбен Даллас]

Вы дробите код на простые сервисы, через DI из иньектите практически в любой класс

Так вы сможете переиспользовать ваши компоненты, например когда в разных контроллерах вам нужно получить список складов вы просто добавляете метод

getWarehouses()

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

Так код чище и работать с ним приятнее

[jazzus]

Корбен Даллас, не чище и не приятнее. Это бессмысленный говнокод. В Ларавел уже есть save delete. Оборачиваеть это в тоже самое нет ни малейшего смысла. getModel и getQuery который возвращает getModel()->getQuery это вообще из категории клиника. Такого еще не видел. Для выноса повторяемых сложных квери в Ларавел есть скоупы, которые можно потом использовать в составе других квери. Вот здесь код чище и приятнее.

например когда вместе с созданием склада создается еще чтотто например филиалы и сотруники к нему

это делается в обсервере. И там это автоматом будет создано и в сидингах и в тестах и тд. Короче надо фреймворк сперва выучить, а потом уже репозиториями интересоваться.

[Корбен Даллас]

jazzus, я думаю нет смысла с вами спорить, так как конструктивного диалога с вами не получится с вашим обсервером, сидингами и тестами.

Вы сначала приведите пример, как у вас организована работа начиная с контроллера и тд, чтобы можно было сравнить ваш и мой код.

Какой процент покрытия в вашем проекте? Что вообще за проект у вас, простенький магазинчик с двумя складами и офисом, CRM или ERP?

А то создается ощущение, что со мной общается диванный эксперт, который не работал в команде скажем человек 5-7 человек, и не знает или не понимает, что кроме вашего мнения есть еще и другие.

[jazzus]

Корбен Даллас, не нужно быть экспертом, чтобы понимать что этот "репозиторий" полная ересь

Answer 1

[jazzus]

HasMany Through
user hasMany warehouses through branches with prices
получать через $user->warehouses прайсы внутри

Или через вложенные отношения в филиалах

$user->branches()
    ->with('warehouses.prices')
    ->get();

Здесь нужно будет форычить branches и в каждом будет $branch->warehouses и по цепочке.

Или запросом на складах

Warehouse::whereHas('branche', function ($query) {
    $query->where('user_id', Auth::id());
})
->get();

прайсы аналогично

Answer 2

[Yariy]

Решил в итоге не мудрить сильно, т.к. время очень ограничено, запилил в модель пользователя функции, которые через join'ы вытаскивают id всех сущностей, связанных с пользователями через несколько таблиц

public function stores(){
        return Store::join('branches', 'stores.branch_id', '=', 'branches.id')->
            join('user_branches', 'branches.id', '=', 'user_branches.branch_id')->
            join('users', 'user_branches.user_id', '=', 'users.id')->
            select('stores.id as id')->
            where('users.id', $this->id);
    }

    public function rates(){
        return Rate::join('stores', 'rates.store_id', '=', 'stores.id')->
        join('branches', 'stores.branch_id', '=', 'branches.id')->
        join('user_branches', 'branches.id', '=', 'user_branches.branch_id')->
        join('users', 'user_branches.user_id', '=', 'users.id')->
        select('rates.id as id')->
        where('users.id', $this->id);
    }

и добаивл фильтр по id

->whereIn('id', Auth::user()->rates()->pluck('id'))