MVC (Laravel) где добавить логику


137

Допустим, всякий раз, когда я выполняю операцию CRUD или изменяю отношения определенным образом, я также хочу делать что-то еще. Например, всякий раз, когда кто-то публикует сообщение, я также хочу что-то сохранить в таблице для аналитики. Может быть, не лучший пример, но в целом есть много этой "сгруппированной" функциональности.

Обычно я вижу этот тип логики в контроллерах. Это нормально, пока вы не захотите воспроизвести эту функцию во многих местах. Когда вы начинаете разбираться в частичках, создавая API и создавая фиктивный контент, становится проблемой сохранять вещи СУХИМЫМИ.

Я видел способы управления этим: события, репозитории, библиотеки и добавление в модели. Вот мое понимание каждого:

Службы: это, где большинство людей, вероятно, поместили бы этот код. Моя основная проблема со службами заключается в том, что иногда трудно найти в них определенную функциональность, и я чувствую, что о них забывают, когда люди сосредоточены на использовании Eloquent. Откуда мне знать, что мне нужно вызывать метод publishPost()в библиотеке, когда я могу это сделать $post->is_published = 1?

Единственное условие, в котором я вижу, что это работает хорошо, - это если вы используете ТОЛЬКО сервисы (и в идеале делаете Eloquent недоступным как-то для всех контроллеров).

В конечном счете кажется, что это просто создаст кучу лишних ненужных файлов, если ваши запросы в целом соответствуют структуре вашей модели.

Репозитории: Насколько я понимаю, это в основном похоже на сервис, но есть интерфейс, позволяющий переключаться между ORM, которые мне не нужны.

События: Я считаю, что это самая элегантная система в некотором смысле, потому что вы знаете, что события вашей модели всегда будут вызываться с помощью методов Eloquent, поэтому вы можете писать свои контроллеры, как обычно. Я могу видеть, что они становятся грязными, и если у кого-то есть примеры крупных проектов, использующих события для критической связи, я бы хотел это увидеть.

Модели: Традиционно у меня были классы, которые выполняли CRUD, а также обрабатывали критическую связь. Это на самом деле упростило задачу, потому что вы знали все функциональные возможности CRUD +, что бы с ним ни было, оно было там.

Просто, но в архитектуре MVC это обычно не то, что я вижу. Хотя, в некотором смысле, я предпочитаю это, а не сервисы, так как найти их немного легче, и меньше файлов для отслеживания. Это может стать немного дезорганизованным все же. Я хотел бы услышать недостатки этого метода и почему большинство людей, кажется, не делают этого.

Каковы преимущества / недостатки каждого метода? Я что-то упускаю?


3
Вы можете минимизировать свой вопрос?
Альфа

3
Также вы можете проверить это .
Альфа

1
«Откуда мне знать, что мне нужно вызывать метод publishPost () в библиотеке, когда я могу просто сделать $ post-> is_published = 1?» Документация?
ceejayoz

одна из красот о eloquent и ORMS - с ними легче работать без большого количества документов?
Сабрина Леггетт

1
Спасибо за публикацию этого. Я борюсь с теми же проблемами и считаю ваш пост и ответ невероятно полезным. В конечном итоге я решил, что Laravel не предоставляет хорошей архитектуры для всего, что выходит за рамки быстрого и грязного сайта Ruby-on-Rails. Повсюду торгует, везде сложно найти классные функции и кучу автомагического мусора. ORM никогда не работал, и если вы используете его, вы, вероятно, должны использовать NoSQL.
Алекс Баркер

Ответы:


171

Я думаю, что все шаблоны / архитектуры, которые вы представляете, очень полезны, если вы следуете принципам SOLID .

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

Краткий ответ: где это имеет смысл для вас (с услугами) .

Длинный ответ:

Контроллеры : Какова ответственность контроллеров? Конечно, вы можете поместить всю свою логику в контроллер, но это ответственность контроллера? Я так не думаю.

Для меня контроллер должен получить запрос и вернуть данные, и это не место для проверки, вызова методов БД и т. Д.

Модели . Является ли это хорошим местом для добавления логики, такой как отправка приветственного письма по электронной почте, когда пользователь регистрируется или обновляет счет голосов для сообщения? Что если вам нужно отправить то же электронное письмо из другого места в вашем коде? Вы создаете статический метод? Что, если для этого письма нужна информация от другой модели?

Я думаю, что модель должна представлять сущность. С Laravel, я использую только класс модели , чтобы добавить такие вещи , как fillable, guarded, tableи отношения (это потому , что я использую Repository Pattern, в противном случае модель будет также иметь save, update, find, и т.д. методы).

Репозитории (Repository Pattern) : В начале я был очень смущен этим. И, как и вы, я подумал: «Ну, я использую MySQL, и все».

Тем не менее, я уравновесил плюсы и минусы использования шаблона репозитория, и теперь я использую его. Я думаю, что сейчас , в этот самый момент, мне нужно будет использовать только MySQL. Но если через три года мне нужно перейти на что-то вроде MongoDB, большая часть работы будет выполнена. Все за счет одного дополнительного интерфейса и $app->bind(«interface», «repository»).

События ( шаблон наблюдателя ): события полезны для вещей, которые могут быть выброшены в любой класс в любой момент времени. Подумайте, например, об отправке уведомлений пользователю. Когда вам нужно, вы запускаете событие, чтобы отправить уведомление в любой класс вашего приложения. Затем у вас может быть такой класс, UserNotificationEventsкоторый обрабатывает все ваши запущенные события для пользовательских уведомлений.

Услуги : до сих пор у вас есть возможность добавить логику в контроллеры или модели. Для меня имеет смысл добавить логику в Сервисы . Посмотрим правде в глаза, Услуги это модное название для классов. И вы можете иметь столько классов, сколько это имеет смысл для вас в вашем приложении.

Возьмите этот пример: недавно я разработал что-то вроде Google Forms. Я начал с CustomFormServiceи в конечном итоге с CustomFormService, CustomFormRender, CustomFieldService, CustomFieldRender, CustomAnswerServiceи CustomAnswerRender. Зачем? Потому что это имело смысл для меня. Если вы работаете с командой, вы должны поставить свою логику там, где это имеет смысл для команды.

Преимущество использования служб по сравнению с контроллерами / моделями заключается в том, что вы не ограничены ни одним контроллером, ни одной моделью. Вы можете создать столько сервисов, сколько вам нужно, в зависимости от дизайна и потребностей вашего приложения. Добавьте к этому преимущество вызова Сервиса в любом классе вашего приложения.

Это долго, но я хотел бы показать вам, как я структурировал свое приложение:

app/
    controllers/
    MyCompany/
        Composers/
        Exceptions/
        Models/
        Observers/
        Sanitizers/
        ServiceProviders/
        Services/
        Validators/
    views
    (...)

Я использую каждую папку для определенной функции. Например, Validatorsкаталог содержит BaseValidatorкласс, отвечающий за обработку валидации, основанный на $rulesи $messagesконкретных валидаторов (обычно один для каждой модели). Я мог бы так же легко поместить этот код в Службу, но для меня имеет смысл иметь для этого специальную папку, даже если она используется только внутри Службы (на данный момент).

Я рекомендую вам прочитать следующие статьи, так как они могут объяснить вам немного лучше:

Дэйл Рис (автор CodeBright): «Я ломаю планку». Именно здесь я собрал все это вместе, хотя я изменил несколько вещей в соответствии со своими потребностями.

Разделение вашего кода в Laravel с использованием репозиториев и сервисов Криса Гуси: этот пост хорошо объясняет, что такое сервис и шаблон репозитория и как они сочетаются друг с другом.

У Laracasts также есть Репозитории с Упрощенной и Единой Ответственностью, которые являются хорошими ресурсами с практическими примерами (даже если вы должны заплатить).


3
отличное объяснение. Вот где я сейчас нахожусь - в текущем проекте я вкладываю свою бизнес-логику в модели, и на самом деле она работает очень хорошо. Нам определенно нужно немного выдумать SOLID, но это еще не доставило нам проблем. Это быстро, немного грязно, но пока наш проект очень ремонтопригоден, потому что он СУХОЙ. Я определенно согласен с тем, чтобы придерживаться их в данный момент, потому что они выполнили свою работу, но в любом будущем проекте я, вероятно, просто пойду с тем, что является стандартным, что, как кажется, стало репозиторием.
Сабрина Леггетт

2
Я рад, что вы нашли способ, который имеет смысл для вас. Просто будьте осторожны с предположениями, которые вы делаете сегодня . Я работал над проектом более 3 лет и в итоге получил контроллеры и модели с 5000+ строками кода. Удачи с вашим проектом.
Луис Круз

также немного грязный, но я думал об использовании черт, чтобы избежать огромных моделей. Таким образом, я могу немного отделить их
Сабрина Леггетт

Эта статья хорошо формулирует, КОГДА имеет смысл пользоваться услугами. В вашем примере формы имеет смысл использовать сервисы, но он объясняет, как он это делает, то есть когда логика напрямую связана с моделью, он помещает ее в эту модель. justinweiss.com/articles/where-do-you-put-your-code
Сабрина Леггетт

Мне очень нравится объяснение. У меня есть один вопрос: вы упомянули, что не следует помещать валидацию в контроллер, так как вы думаете, где лучше всего проводить валидацию? Многие предлагают поместить его в расширенный класс Request (а также то, что мы в настоящее время делаем), но что, если я хочу не просто проверить запрос http, но также выполнить команду artisan и т. Д., Действительно ли это хорошее место?
Кингшарк

24

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

В итоге я использовал существующую структуру, которую предоставляет Laravel, а это означает, что я хранил свои файлы в основном в виде Model, View и Controller. У меня также есть папка «Библиотеки» для повторно используемых компонентов, которые на самом деле не являются моделями.

Я не оборачивал свои модели в услуги / библиотеки . Все приведенные причины не на 100% убедили меня в пользе использования услуг. Хотя я могу ошибаться, насколько я вижу, они просто приводят к множеству дополнительных почти пустых файлов, которые мне нужно создавать и переключаться между ними при работе с моделями, а также действительно уменьшают преимущества использования eloquent (особенно когда речь идет о ПОЛУЧЕНИИ моделей). например, с использованием нумерации страниц, областей и т. д.).

Я поставил бизнес - логику в моделях и доступ красноречивых непосредственно из моих контроллеров. Я использую несколько подходов, чтобы убедиться, что бизнес-логика не обойдется:

  • Аксессоры и мутаторы: у Laravel есть отличные аксессоры и мутаторы. Если я хочу выполнить действие при каждом перемещении сообщения из черновика в опубликованное, я могу вызвать его, создав функцию setIsPublishedAttribute и включив в нее логику
  • Переопределение Create / Update и т. Д. Вы всегда можете переопределить методы Eloquent в своих моделях для включения пользовательских функций. Таким образом, вы можете вызывать функциональность в любой операции CRUD. Редактировать: я думаю, что есть ошибка с переопределением create в более новых версиях Laravel (поэтому я использую события, теперь зарегистрированные в boot)
  • Проверка: я проверяю свою проверку таким же образом, например, я запускаю проверку, переопределяя функции CRUD, а также средства доступа / мутаторы, если это необходимо. См. Esensi или dwightwatson / validating для получения дополнительной информации.
  • Магические методы: я использую методы __get и __set моих моделей, чтобы использовать функциональные возможности там, где это необходимо.
  • Расширение Eloquent: если вы хотите выполнить все обновления / создания, вы можете даже расширить eloquent и применить его к нескольким моделям.
  • События: Это прямое и в общем согласованное место, чтобы сделать это. Я думаю, что самый большой недостаток событий заключается в том, что исключения трудно отследить (возможно, это не новый случай с новой системой событий Laravel). Я также люблю группировать свои события по тому, что они делают, а не по тому, как они называются ... например, иметь подписчика MailSender, который прослушивает события, отправляющие почту.
  • Добавление событий Pivot / BelongsToMany. Одна из вещей, с которой я долго боролся, заключалась в том, как связать поведение с модификацией отношений ownToMany. Например, выполнение действия всякий раз, когда пользователь присоединяется к группе. Я почти закончил полировать пользовательскую библиотеку для этого. Я еще не опубликовал это, но это функционально! Постараюсь опубликовать ссылку в ближайшее время. РЕДАКТИРОВАТЬ Я закончил превращать все мои стержни в нормальные модели, и моя жизнь стала намного проще ...

Решение проблем людей с использованием моделей:

  • Организация: Да, если вы добавите больше логики в модели, они могут быть длиннее, но в целом я обнаружил, что 75% моих моделей все еще довольно маленькие. Если я решил организовать более крупные, я могу сделать это, используя черты (например, создать папку для модели с некоторыми другими файлами, такими как PostScopes, PostAccessors, PostValidation и т. Д.). Я знаю, что это не обязательно то, для чего нужны черты, но эта система работает без проблем.

Дополнительное примечание: мне кажется, что оборачивать ваши модели в сервисы - это все равно, что иметь швейцарский армейский нож с большим количеством инструментов и строить вокруг него еще один нож, который в основном делает то же самое? Да, иногда вы можете захотеть скотчить лезвие или убедиться, что два лезвия используются вместе ... но обычно есть другие способы сделать это ...

КОГДА ИСПОЛЬЗОВАТЬ УСЛУГИ : В этой статье очень хорошо сформулированы ОТЛИЧНЫЕ примеры того, когда пользоваться услугами ( подсказка: это не очень часто ). Он говорит, что в основном, когда ваш объект использует несколько моделей или моделей в странных частях их жизненного цикла, это имеет смысл. http://www.justinweiss.com/articles/where-do-you-put-your-code/


2
Интересные и обоснованные мысли. Но мне любопытно - как вы проводите модульное тестирование своей бизнес-логики, если она связана с моделями, которые связаны с Eloquent, который связан с базой данных?
JustAMartin

code.tutsplus.com/tutorials/… или вы можете использовать события, как я сказал, если вы хотите разбить его дальше
Сабрина Леггетт

1
@ JustMartin Вы уверены, что не можете просто использовать базу данных в своих модульных тестах? В чем причина этого не делать? Многие люди согласны с тем, что часто можно использовать базу данных в модульных тестах. (включая Мартина Фаулера, martinfowler.com/bliki/UnitTest.html : «Я не рассматриваю использование двойных для внешних ресурсов как абсолютное правило. Если общение с ресурсом стабильно и достаточно быстро для вас, то нет причин не делать этого». это в твоих модульных тестах ")
Алекс П.

@ AlexP11223 Да, это имеет смысл. Я попытался интегрировать SQLite в качестве своей тестовой базы данных, и в целом все прошло хорошо, хотя SQLite имеет некоторые серьезные ограничения, которые необходимо учитывать при миграциях Laravel и пользовательских запросах (если таковые имеются). Конечно, тогда это не просто модульные тесты, а функциональные тесты, но это еще более эффективно. Тем не менее, если вы хотите протестировать свою модель в полной изоляции (как строгий модульный тест), может потребоваться заметное количество дополнительного кода (макеты и т. Д.).
JustAMartin

22

То, что я использую для создания логики между контроллерами и моделями, - это создание сервисного уровня . По сути, это мой поток для любых действий в моем приложении:

  1. Контроллер получает запрошенное пользователем действие и отправляет параметры, а все делегирует классу обслуживания.
  2. Класс обслуживания выполняет всю логику, связанную с операцией: проверка ввода, регистрация событий, операции с базой данных и т. Д.
  3. Модель содержит информацию о полях, преобразовании данных и определениях валидации атрибутов.

Вот как я это делаю:

Это метод контроллера для создания чего-либо:

public function processCreateCongregation()
{
    // Get input data.
    $congregation                 = new Congregation;
    $congregation->name           = Input::get('name');
    $congregation->address        = Input::get('address');
    $congregation->pm_day_of_week = Input::get('pm_day_of_week');
    $pmHours                      = Input::get('pm_datetime_hours');
    $pmMinutes                    = Input::get('pm_datetime_minutes');
    $congregation->pm_datetime    = Carbon::createFromTime($pmHours, $pmMinutes, 0);

    // Delegates actual operation to service.
    try
    {
        CongregationService::createCongregation($congregation);
        $this->success(trans('messages.congregationCreated'));
        return Redirect::route('congregations.list');
    }
    catch (ValidationException $e)
    {
        // Catch validation errors thrown by service operation.
        return Redirect::route('congregations.create')
            ->withInput(Input::all())
            ->withErrors($e->getValidator());
    }
    catch (Exception $e)
    {
        // Catch any unexpected exception.
        return $this->unexpected($e);
    }
}

Это класс обслуживания, который выполняет логику, связанную с операцией:

public static function createCongregation(Congregation $congregation)
{
    // Log the operation.
    Log::info('Create congregation.', compact('congregation'));

    // Validate data.
    $validator = $congregation->getValidator();

    if ($validator->fails())
    {
        throw new ValidationException($validator);
    }

    // Save to the database.
    $congregation->created_by = Auth::user()->id;
    $congregation->updated_by = Auth::user()->id;

    $congregation->save();
}

И это моя модель:

class Congregation extends Eloquent
{
    protected $table = 'congregations';

    public function getValidator()
    {
        $data = array(
            'name' => $this->name,
            'address' => $this->address,
            'pm_day_of_week' => $this->pm_day_of_week,
            'pm_datetime' => $this->pm_datetime,
        );

        $rules = array(
            'name' => ['required', 'unique:congregations'],
            'address' => ['required'],
            'pm_day_of_week' => ['required', 'integer', 'between:0,6'],
            'pm_datetime' => ['required', 'regex:/([01]?[0-9]|2[0-3]):[0-5]?[0-9]:[0-5][0-9]/'],
        );

        return Validator::make($data, $rules);
    }

    public function getDates()
    {
        return array_merge_recursive(parent::getDates(), array(
            'pm_datetime',
            'cbs_datetime',
        ));
    }
}

Для получения дополнительной информации об этом способе я использую, чтобы организовать свой код для приложения Laravel: https://github.com/rmariuzzo/Pitimi


Похоже, что сервисы - это то, что я назвал библиотеками в своем посте. Я думаю, что это лучше, чем репозитории, если вам не нужно использовать несколько ORMS, но проблема в том, что вам нужно перенести весь проект (что вам не нужно делать с событиями), и кажется, что Это просто зеркально отражает структуру модели, поэтому у вас есть все эти дополнительные файлы. Почему бы просто не включить его в модели? По крайней мере, так у вас нет лишних файлов.
Сабрина Леггетт

Это интересный вопрос @SabrinaGelbart, меня научили позволять моделям представлять объекты базы данных и не содержать никакой логики. Вот почему я создал эти дополнительные файлы, названные сервисами: для хранения всей логики и любых дополнительных операций. Я не уверен, в чем весь смысл событий, которые вы описали ранее, но я думаю, что с помощью сервисов и с помощью событий Laravel мы можем создать все сервисные методы для запуска событий в начале и в конце. Таким образом, любое событие может быть полностью отделено от логики. Что вы думаете?
Рубенс Мариуццо

Меня тоже учили о моделях ... было бы неплохо получить хорошее объяснение почему (может быть, проблемы с зависимостями)?
Сабрина Леггетт

Мне нравится этот подход! Я искал в Интернете, чтобы понять, как мне следует обращаться с логикой модели, просмотрел репозитории, но это показалось слишком сложным и бесполезным для некоторого использования. Услуги это хорошая идея. Мой вопрос: после создания папки Services в папке приложения, нужно ли включать ее в bootstrap / start.php или где-либо еще для загрузки, потому что я посмотрел, ваш git не может ее найти? @RubensMariuzzo. Это автоматически становится доступным через приложение? поэтому мы можем просто использовать CongregationService :: getCongregations (); ??
Огужан

1
Если все, что вы делаете - это, $congregation->save();возможно, вам не понадобятся репозитории. Однако вы можете заметить, что ваши потребности в доступе к данным со временем возрастут. Вы можете начать нуждаться в $congregation->destroyByUser()или $congregationUsers->findByName($arrayOfSelectedFields);и так далее. Почему бы не отсоединить ваши услуги от потребностей доступа к данным. Позвольте остальной части вашего приложения работать с объектами / массивами, возвращенными из репозиториев, и просто обрабатывать манипуляции / форматирование / и т.д ... Ваши репозитории будут расти (но разбить их на разные файлы, в конечном итоге сложность проекта должна где-то находиться).
программер

12

На мой взгляд, у Laravel уже есть много вариантов для хранения вашей бизнес-логики.

Короткий ответ:

  • Используйте Requestобъекты laravel для автоматической проверки вашего ввода, а затем сохраните данные в запросе (создайте модель). Поскольку все входные данные пользователей непосредственно доступны в запросе, я считаю, что имеет смысл выполнить это здесь.
  • Используйте Jobобъекты laravel для выполнения задач, требующих отдельных компонентов, а затем просто отправляйте их. Я думаю, что Jobвключает в себя классы обслуживания. Они выполняют задачу, такую ​​как бизнес-логика.

Длинный (er) ответ:

Использовать репозитории, когда это необходимо: репозитории обязательно переполнены, и большую часть времени просто используются в качестве accessorмодели. Я чувствую, что они определенно имеют какое-то применение, но если вы не разрабатываете массивное приложение, которое требует такой гибкости, чтобы вы могли полностью избавиться от лишнего, оставайтесь в стороне от репозиториев. Вы поблагодарите себя позже, и ваш код будет намного проще.

Спросите себя, есть ли вероятность того, что вы собираетесь менять фреймворки PHP или использовать тип базы данных, который laravel не поддерживает.

Если ваш ответ «Наверное, нет», не используйте шаблон репозитория.

В дополнение к вышесказанному, пожалуйста, не бейте шаблон поверх превосходного ORM, такого как Eloquent. Вы просто добавляете сложность, которая не требуется, и она не принесет вам никакой пользы.

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

Я чувствую, что у Laravel есть всестороннее решение MVCлогической проблемы. Это просто вопрос или организация.

Пример:

Запрос :

namespace App\Http\Requests;

use App\Post;
use App\Jobs\PostNotifier;
use App\Events\PostWasCreated;
use App\Http\Requests\Request;

class PostRequest extends Request
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'title'       => 'required',
            'description' => 'required'
        ];
    }

    /**
     * Save the post.
     *
     * @param Post $post
     *
     * @return bool
     */
    public function persist(Post $post)
    {
        if (!$post->exists) {
            // If the post doesn't exist, we'll assign the
            // post as created by the current user.
            $post->user_id = auth()->id();
        }

        $post->title = $this->title;
        $post->description = $this->description;

        // Perform other tasks, maybe fire an event, dispatch a job.

        if ($post->save()) {
            // Maybe we'll fire an event here that we can catch somewhere else that
            // needs to know when a post was created.
            event(new PostWasCreated($post));

            // Maybe we'll notify some users of the new post as well.
            dispatch(new PostNotifier($post));

            return true;
        }

        return false;
    }
}

Контроллер :

namespace App\Http\Controllers;

use App\Post;
use App\Http\Requests\PostRequest;

class PostController extends Controller
{

   /**
    * Creates a new post.
    *
    * @return string
    */
    public function store(PostRequest $request)
    {
        if ($request->persist(new Post())) {
            flash()->success('Successfully created new post!');
        } else {
            flash()->error('There was an issue creating a post. Please try again.');
        }

        return redirect()->back();
    }

   /**
    * Updates a post.
    *
    * @return string
    */
    public function update(PostRequest $request, $id)
    {
        $post = Post::findOrFail($id);

        if ($request->persist($post)) {
            flash()->success('Successfully updated post!');
        } else {
            flash()->error('There was an issue updating this post. Please try again.');
        }

        return redirect()->back();
    }
}

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

Затем вы можете использовать точно такой же постоянный метод для обновления сообщений, так как мы можем проверить, существует ли уже сообщение и выполнить чередующуюся логику при необходимости.


но - разве рабочие места не должны быть поставлены в очередь? Иногда мы, вероятно, хотим, чтобы это ставилось в очередь, но не всегда. Почему бы не использовать команды вместо этого? Что, если вы хотите написать некоторую бизнес-логику, которая может быть выполнена в виде команды, события или в очереди?
Сабрина Леггетт

1
Рабочие места не должны быть поставлены в очередь. Вы указываете это, внедряя интерфейс в работу, ShouldQueueкоторую предоставляет Laravel. Если вы хотите написать бизнес-логику в команде или событии, просто запустите задание внутри этих событий / команд. Рабочие места Laravels чрезвычайно гибки, но, в конце концов, они просто классы обслуживания.
Стив Бауман
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.