Best practices при написании приложений на Laravel?

Question

[Muhammad]

Недавно начал осваиваить Dependency Injection и репозитории в Laravel и сразу же возникло несколько вопросов:
1. Где хранить файла репозиториев? Я создаль папку Repositories и добавил ее в Composer. Правильно ли я сделал?
2. Нужно ли разбивать папку с репозиториями на подпапки (UserRepository, MailerRepositiory и т.д.)
3. Где лучше биндить интерфейсы к реализации - в хелпере bingings или в сервис-провайдере?
4. Где хранить сервис провайдеры? Пока хранятся в папке Providers

Другое:

5. У модели User есть метод register, где происходит валидация. Сейчас в случае ошибки выбрасывается кастомный InvalidDataException (или NotFoundException, в зависимости от ситуации), который лежит в папке с моделями, а контроллере уже происходит обработка:

try {
	$user = $this->users->register($data);
} catch (InvalidDataException $e) {
	return Redirect::back()->with('global', $e->getMessage())->withInput($data)->withErrors($e->getErrors());
}

Правильно ли так делать или лучше вынести его в отдельную папку?
6. Как тестировать отправку E-mail (без различных catcher-ов и т.д.)?

Answer 1

[Сергей Протько]

для начала перестаньте мыслить папками и начните мыслить пространствами имен

1) где хотите. Простой вариант - в неймспейсе Repository. В целом почитайте про шаблон репозиторий
2) А какой в этом смысл? Есть смысл делить по поддерживаемым хранилищам (Database, InMemory, etc), только так у нас могут быть две реализации UserRepository
3) в сервис провайдере логичнее.
4) Там и храните, еще можно переименовать в ServiceProvider
5) Обычно регистрация юзера это new User, или в случае Laravel - статическая фабрика... или сервис. Вообще валидация тоже должна происходить на уровне контроллера, но тут уж как выходит.
6) без различных катчеров - у swift mailer есть spool, но как по мне это не столь удобно.

Comments

[Muhammad]

А как лучше делать биндин: все в одном провайдере или на каждый репозиторий один провайдер?

[Muhammad]

Немного не понятно почему валидация должна происходить на уровне контроллера? Когда я читал в про MVC, в том числе и Википедии, там говорилось, что вся логика быть в моделях. Если я верно понял, то туда входит и валидация. Или я не прав? Еще у меня есть API который дает тот же функционал (добавление, удаление), значит придется дублировать код. Или нужно вынести Валидатор в другое место?

[Сергей Протько]

Muhammad: вся бизнес логика должна быть в модели, и есть определенные нюансы (в частности бизнес логика может быть в сервисах, а модели AR - чисто persistence layer). А валидация - это часть обработка входных данных, это дело должно обрабатываться в контроллере, в модель данные должны попадать уже проверенные. Модель в принципе не должна иметь невалидного состояния. Все остальное - определенные упрощения.

Answer 2

[D']

В основно Сергей Протько всё правильно ответил, дополню несколько пунктов:

5) Валидацию нужно делать в контроллере на уровне FormRequest. Метод register в модели не нужен. Можно сделать сервис UserRegistration, или использовать команды (раздел Jobs).

6) Отправку Email не нужно тестировать. Максимум что можно сделать, это замокать фасад или интерфейс Mailer и проверить что он вызывается.

Comments

[Сергей Протько]

6) в функциональных тестах катчеры неплохо иметь.

[D']

Сергей Протько: ниразу не сталкивался с задачей тестировать именно текст письма. Обычно просто мокаю Mailer, и проверяю что он вызывается shouldReceive('send')->once().
Но согласен, задачи разные у всех, может кому-то это и нужно.

[Сергей Протько]

D' Normalization: ну у меня на самом деле тоже лишь пару раз такой кейс был. Но обычно катчеры всеравно ставлю, ибо верстку писем проверять проще.

[Muhammad]

D' Normalization: знаки про моки, но не понимал, для чего они нужны пока не нашел эту статью: www.sitepoint.com/mock-test-dependencies-mockery

[Muhammad]

D' Normalization: не могли бы подробнее рассказать про UserRegister, т.е. как это реализовать?

[D']

Muhammad: Я обычно делаю отдельный сервис для регистрации. Например App\Services\UserRegistration, который занимается всем связанным с регистрацией (например создание дополнительных полей в БД, активация юзера, создание сессии и т.д. В общем все те вещи, которые нужно сделать во время регистрации.). UserRegistration это просто отдельный класс с методом register, который принимает данные для регистрации.
Так же он кидает событие UserRegistered, которое уходит в очередь и затем обрабатывается.

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

[D']

Muhammad: просто если мне потребуется сделать регистрацию юзера не из контроллера, а например из админки, то мне не придется дублировать весь этот код, а просто вызвать метод у сервиса.

Делать метод register в модели не правильно, по идеалогии Laravel. Для этого нужно выделять отдельный сервис\job

[D']

Muhammad: В модели можно сделать метод register, который будет просто создавать юзера. Но при регистрации обычно нужно делать еще много дополнительных телодвижений, которые не должны быть в модели.

[Muhammad]

D' Normalization: т.е. если у меня есть AccountController и в нем метод postCreate, то мне следует из него сразу же вызвать Service? Или сначала получить данные, а затем передать в сервис (кажется мне более разумным)? Затем там проходит валидация (метод или отдельный объект?) и выбрасывается исключение в случе ошибки. Кто должен его обработать: сервис или контроллер? И насчет исключений - где их лучше хранить (именно исключения валидации)?

[Сергей Протько]

D' Normalization: да, именно так, достать данные из запроса. провалидировать и запихнуть в сервис в том формате в котором он хочет.

[D']

Muhammad: валидировать, как я писал выше, должен FormRequest класс. Я дал ссылку как это правильно делать.
Таким образом в $request уже будут валидные данные, которые можно просто передавать в сервис регистрации.

public function postCreate(RegisterUserRequest $request)
{
$user = $this->userRegistration->register($request->all());
return __ возвращаем ответ __;
}

Для исключений есть отдельная папка app/Exceptions, но хранить их можно где угодно. Всё зависит от структуры проекта.

Я обычно переопределяю метод render в app/Exceptions/Handler.php и обрабатываю все ошибки так, как мне это нужно.
Таким образом у меня чистые контроллеры, без тысячи try/catch блоков.

[Muhammad]

D' Normalization: еще один вопрос. Как вы проводите тестирование связанное с БД (вторая база данных, SQLite в памяти, другое)?

[D']

Muhammad: т.е? Просто настраиваю sqlite :memory: и всё.

[Muhammad]

D' Normalization: да, именно это я и хотел узнать, спасибо