Laravel по-русски

"ты пишешь с помощью кучи join вместо использования связей, тогда используй репозитории."

Может и от сервиса не стоит отказываться? Или он скорее не нужен все же когда используется в одной форме.. Но если с помощью него повторный код убивается то видимо и сервис нужен..

Понимаю, но не считаю это красивым. Считаю что нужен класс (репо) в котором работа с юзеров и с ближайшим к нему связанным функционалом той же активацией и сменой мейла..

Делать все в eloquent моделях кажется неверно. А если у меня 2-3 равнозначные таблицы для работы с каким то функционалом. Тк в функционале как правило join'ы или иные тесные использования этих таблиц, то как то не очень удобно будет выбирать в какой из 2-3 моделек это писать. По мне лучше в таком случае написать один класс, из которого уже вызывать Eloquent методы, для всех трех таблиц. А местами и DB:raw для этих же таблиц...

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

Другие ответы подожду.. Но пока кроме тебя все молчат...

Экземпляр объекта $item $user итд, на мой взгляд не должен иметь методов Eloqent через него не должны искаться другие юзеры итд... А это возможно. Или я неверно понял??

"То их перемещаешь в модель."

В какую? В модель User или EmailChange ?

"Простой пример методов в модели:"

А можешь показать, примерно весь класс модели в таком случае для понимания?

"Если ты в репозитории используешь запросы в Eloquent - это то же самое, что ты в классе модели используешь те же запросы"

Экземляр репо не может относится к конкретному объекту из таблицы, а экземпляр модели только этим и является. Сравни $item = Item::find(2); тут мы имеем item c id =2 и выполнять скажем $item->getSomeItems(); просто глупо. Получается вещь с ид 2, и обращаемся к ней почему, за несколькими другими вещями.. Что кажется совершенно не логично. В случае с repo не так. тк он не относится к конкретной вещи, а работает с наборами вещей, тк не наследует от Eloquent.

Может тупой пример, но понятный или нет?

"Нужны ли контракты/фасады все же для каждого такого класса.
Фасады нужны для удобства, мне больше нравится использовать контейнер. Контракты - полностью зависит от твоей архитектуры."

Да я тоже за  просто привязку классу к контейнеру и за его инжект в контроллере. Видимо для этого нужен просто app bind и все.

С этим ладно. Интереснее вопросы про Репо, про то что не хочу описывать бизнес логику там где наследуется от Eloquent и про то куда девать бизнес логику активации и смены мейла, в UserRepo/UserModel или куда еще?

"классе модели используешь те же запросы"

Но класс модели то наследует от  use Illuminate\Database\Eloquent\Model; вот в чем дело... а репо нет..

А сервисы

class ChangeEmailService implements ChangeEmailContract
{

    protected $mailer;
    
    protected $changeEmailRepo;
    
    public function __construct(ChangeEmailRepositoryContract $changeEmailRepo)
    {
       $this->changeEmailRepo = $changeEmailRepo;
    }
  
    public function sendChangeEmailMail($user, $email)
    {
        $token = $this->changeEmailRepo->createEmailChange($user, $email);
        
        \Mail::to($email)->send(
            new \App\Mail\ChangeEmail(array(
                'email' => $email,
                'token' => $token,
            ))
        );
    }
    
    public function setEmail($token, $email)
    {
        $changeEmail = $this->changeEmailRepo->getChangeEmailByTokenAndEmail($token, $email);
        
        if ($changeEmail === null) {
            throw new ChangeEmailNotFoundException();
        }
        
        $user = User::find($changeEmail->user_id);
        
        if (!$user) {
            throw new ChangeEmailNotFoundException();
        }

        $user->email = $email;

        $user->save();

        $this->changeEmailRepo->deleteChangeEmail($token);

        return $user;

    }
    
}

class ActivateEmailService implements ActivateEmailContract
{

    protected $mailer;
    
    protected $activationEmailRepo;
    
    public function __construct(ActivateEmailRepositoryContract $activationEmailRepo)
    {
       $this->activationEmailRepo = $activationEmailRepo;
    }
    
    public function sendActivationMail($user)
    {
        if (!$user || $user->verified) {
            throw new ActivateUserNotFoundException();
        }
        
        $token = $this->activationEmailRepo->createActivation($user);
        
        \Mail::to($user->email)->send(
            new \App\Mail\ActivateEmail(array(
                'email' => $user->email,
                'token' => $token,
            ))
        );
        
    }
    
    public function activateUser($token, $email)
    {
        $activation = $this->activationEmailRepo->getActivationByToken($token);
         
        if ($activation === null) {
            throw new ActivateUserNotFoundException();
        }
        $user = User::find($activation->user_id);
        
        if (!$user) {
            throw new ActivateUserNotFoundException();
        }

        $user->verified = true;

        $user->save();

        $this->activationEmailRepo->deleteActivation($token);

        return $user;

    }
  
}

Что просто вынести в контроллеры??

Теперь другой вопрос. Вот эти модели или уж репо. Для Юзера, для Юзерский файлов в общем для крупных кусков бизнес логике. Как правильней привязать к контейнеру?

В AppService или каждый в своем провайдере? Нужны ли контракты/фасады все же для каждого такого класса.

И еще ты не ответил стоит ли методы активации и смены мейла пихать в модель(репо) юзера, или это отдельные модели(репо) должны быть…

Вот это ответь и отстану… И возможно через пару дней покажу переписанный код…

«С файлами работать можно в контроллере, если это 1-2 строки. Если что-то серьезное, тогда двигаешь логику в отдельный класс.»

Уверен, что сложнее. Про отдельные готовые пакеты пока не уверен. Для файлов скорее нет. Для подписок и оплаты возможно.

Опять же отдельный класс… Но надеюсь не наследованный от Eloquent…

И в пакетах что видел, тоже такого нет…