Модели Laravel — Использование рабочих мест и услуг
Мне было интересно, как большинство разработчиков используют эти два инструмента Laravel.
В Ларавеле, Вы можете работать с бизнес-логикой с помощью Сервисов или с помощью Джобса. (давайте поговорим только о заданиях без очереди, только о тех, которые выполняются в одном и том же процессе).
Например, пользователь хочет создать объект, скажем, книгу, вы можете обрабатывать создание объекта с помощью службы или отправки задания.
Используя работу это было бы что-то вроде этого:
class PostBook extends Job
{
...
public function handle(Book $bookEntity)
{
// Business logic here.
}
...
}
class BooksController extends Controller
{
public function store(Request $request)
{
...
dispatch(new PostBook($request->all()));
...
}
}
Использование сервиса, это было бы что-то вроде этого:
class BookService
{
public function store(Request $request)
{
// Business logic here.
}
}
class BooksController extends Controller
{
public function store(Request $request)
{
...
// I could inject the service instead.
$bookService = $this->app()->make(App\Services\BookService::class);
$bookService->store($request);
...
}
}
Вопрос в том, как вы предпочитаете использовать тот или иной путь? И почему?
Конечно, есть две «школы» в этом вопросе, но я бы хотел понять плюсы & минусы каждого.
Решение
«Бизнес-логика» может быть обработана с что-нибудь, так что кажется, что на самом деле спрашивают, какой вариант лучше повторить ту же бизнес-логику без повторения кода.
работа класс обычно делает одна вещь, как определено его handle() метод. Трудно исключить задания из очереди из сравнения, потому что их синхронный запуск обычно сводит на нет цель, заключающуюся в обработке дорогостоящих или ненадежных действий (таких как вызов веб-службы). после текущий запрос был выполнен, и пользователю был показан ответ.
Если бы все задания были синхронными, это не сильно отличалось бы от определения функция для вашей бизнес-логики. На самом деле это очень близко к тому, что делает синхронная работа: где-то в стеке вызовов она заканчивается call_user_func([$job, 'handle']) чтобы вызвать единственный метод на вашем объекте работы. Важнее, синхронная работа не имеет механизма для повторной попытки задания, которые могут быть не выполнены из-за внешних причин, таких как сбои сети.
Сервисы, с другой стороны, это простой способ инкапсулировать логику вокруг составная часть, и они могут сделать больше чем одно. В этом контексте компонент может рассматриваться как часть вашего приложения, которая может быть заменена на другую реализацию без необходимости изменения других частей, которые его использовали.
Подумайте, не хранили ли вы книги, вставив их в базу данных, а разместив их во внешнем API. Вы можете иметь BookRepository оказание услуг что не только имеет store() метод, но также имеет get(), update(), list(), delete()или любое количество других методов. Все эти запросы используют общую логику для аутентификации во внешнем веб-сервисе (например, добавление заголовков к запросам), и ваш класс BookRepository может инкапсулировать эту повторно используемую логику. Вы можете использовать этот класс обслуживания внутри запланированных команд ремесленников, веб-контроллеров, контроллеров API, заданий, промежуточного программного обеспечения и т. Д. — без повторения кода.
Используя этот пример, вы можете создать работа для сохранения новой книги, чтобы вы не заставляли пользователей ждать при медленных ответах API (и она может повторить попытку при сбоях). Внутренне ваша работа зовет вас Сервисы store() метод, когда он работает. Работа, выполняемая службой, определяется работой.
Другие решения
Других решений пока нет …