Недавно я закончил читать книгу ООП, и я решил создать проект с Laravel Framework.
В книге автор рекомендовал разделить классы по типам: DTO, BL и репозитории.
Laravel заставил меня немного запутаться, как организовать мою систему.
Я думал сделать что-то вроде этого:
Структура файлов:
app
BL
RegisterUser.php
Repositories
UserRepository.php
Затем сделать, например:
// UserController
public function register($name, $email)
{
try {
$this->registerUser->fromWeb($name, $email);
}
catch(..) {
}
return View::make(....);
}
// RegisterUser
public function fromWeb($name, $email) {
if(...)
throw new Exception();
$this->userRepository->createUser($name, $email);
}
// userRepository
public function createUser($name, $email) {
// Insert to DB
}
Я не спрашиваю конкретно об этом действии, я спрашиваю в целом, правильно ли так работать.
Кроме того, нужно ли использовать DTO в модели? Если так, как это должно соответствовать?
Я бы не сказал, что есть какой-то правильный путь, но на первый взгляд мне кажется, что это слишком много слоев.
Я считаю, что модели будут вашими DTO. Они могут включать в себя основные аксессоры / мутаторы, если они вам нужны, в противном случае Eloquent отлично справляется с остальными. Многие люди также используют модели для проверки, хотя это зависит от вас. Существует удивительный пакет под названием Ardent, который сделает вашу жизнь намного проще, если это звучит как хорошая идея. Для общего рабочего процесса Laravel, я думаю, это имеет большой смысл.
Все разные, но я обычно склоняюсь к более общему уровню обслуживания, где мои репозитории отвечают за обработку всей бизнес-логики. Короче говоря, я использую их, чтобы мои контроллеры были максимально легкими. То, как это переводится на то, что вы прочитали, в основном объединяет бизнес-логику и репозитории в просто репозитории.
Тогда контроллеры будут строго отвечать за управление потоком данных между уровнем сервиса (репозиториями) и представлениями.
Других решений пока нет …