Модели Laravel - Использование рабочих мест и услуг - PullRequest
Новая
       18

Модели Laravel - Использование рабочих мест и услуг

0 голосов
/ 19 октября 2018

Мне было интересно, как большинство разработчиков используют эти два инструмента 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);
        ...
    }
}

Вопрос в том, как вы в основном выбираете использовать тот или иной путь? И почему?

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

1 Ответ

0 голосов
/ 19 октября 2018

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

A Класс Job обычно выполняет одну вещь , как определено его методом handle().Трудно исключить задания из очереди из сравнения, поскольку их синхронный запуск обычно сводит на нет цель, заключающуюся в обработке медленных, дорогостоящих или ненадежных действий (таких как вызов веб-API) после текущего запроса был выполнени пользователю был показан ответ.

Если все задания должны были быть синхронными, это не сильно отличалось бы от определения функции для вашей бизнес-логики.Это на самом деле очень близко к тому, что выполняет диспетчеризация синхронного задания: где-то в стеке вызовов он запускает call_user_func([$job, 'handle']), чтобы вызвать единственный метод для вашего объекта задания.Что еще более важно, в синхронном задании отсутствует механизм для повторной попытки заданий, которые могли быть неудачными из-за внешних причин, таких как сбои сети.

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

Подумайте, не хранили ли вы книги, вставив их в базу данных, а вместо этогопутем публикации на внешний API.У вас может быть служба BookRepository , которая не только имеет метод store(), но также имеет get(), update(), list(), delete() или любое количество других методов.Все эти запросы используют общую логику для аутентификации во внешнем веб-сервисе (например, добавление заголовков к запросам), и ваш класс BookRepository может инкапсулировать эту повторно используемую логику.Вы можете использовать этот класс обслуживания внутри запланированных ремесленных команд, веб-контроллеров, контроллеров API, заданий, промежуточного программного обеспечения и т. Д. - без повторения кода.

Используя этот пример, вы можете создать Задание для хранения новой книги, чтобы не заставлять пользователей ждать при медленном отклике API (и он может повторить попытку при сбое),Внутренне ваша работа вызывает ваш метод Service store() при запуске.Работа, выполняемая службой, определяется заданием.

...