Такой вопрос, при использовании сервисного слоя где расположить классы, которые используются сервисом? Например: в системе есть заказы, что-бы заказ был оформлен автоматически он должен соответствовать определённым требованиям (правилам). Предположим у нас есть сервис OrderService в котором есть метод attemptAutoCheckout() (попытка автоматического оформления, собственно метод, который будет проверять заказ и в случае успеха - оформлять). Но тут фигурирует не только сервис, а ещё класс OrderValidator который осуществляет проверку по определённым правилам, реализующим интерфейс RuleInterface .

Получается, что в контроллере мы вызываем

$this->orderService->attemptAutoCheckout($order);

а уже внутри этого метода у нас:

$this->orderValidator->addRule(new FooRule());
$this->orderValidator->addRule(new BarRule());

if (! $this->orderValidator->validate($order)) {
  $errors = $this->orderValidator->getErrorMessages();
}

Вопрос, куда разместить OrderValidator , RuleInterface , FooRule , BarRule ? Если просто закинуть рядом с OrderService в директорию Services/ то непонятно что к чему относится (а ведь OrderValidator как бы логически связан именно с OrderService ), в отдельную директорию вынести? Или что? Как бы вы поступили?

О!

900 участников!

Та-даааам!

цифры не показатель)

А что - показатель?

Ну да, обычно 50% минимум вообще неактивных, даже в телеграм в общем

Количество общающихся наверн) нужен combot))

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

Но все равно именно активных мало, помогают одни и те же

Для этого тебе надо самому ее в 'data' обернуть.

Прлсто заюзай пакет и он сам будет все оборачивать. Подробнее в ридми читани: https://github.com/andrey-helldar/api-response

Есть вариант много лучше. Твой подход очень жирный по ресурсам

Не, data это ключ. Ему надо вручную создать массив с ключом data и возвращать

Логи...

При отправке тебе надо ключ не attributes совать, а form_params либо json:
http://docs.guzzlephp.org/en/stable/request-options.html?highlight=json#json

$this->orderService->attemptAutoCheckout($order);

$this->orderValidator->addRule(new FooRule());
$this->orderValidator->addRule(new BarRule());

if (! $this->orderValidator->validate($order)) {
  $errors = $this->orderValidator->getErrorMessages();
}

App\Validations\Orders\OrderValidation

App\Contracts\RuleInterface

App\Rules\FooRule

Есть такая беда, да

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

Делаешь релейшн hasMany и создаёшь записи через createMany: https://laravel.com/docs/6.x/eloquent-relationships#the-create-method


$post = App\Post::find(1);

$post->comments()->createMany([
   [
       'message' => 'A new comment.',
   ],
   [
       'message' => 'Another new comment.',
   ],
]);

mavinoo/laravel-batch посмотри сюда.

Rule это не контракт а именно интерфейс, контракт даёт право на что-либо (добавляет тип, он может быть вообще без сигнатур), а интерефейс на то и интерфейс, что-бы описать интерфейс, лол. Я к тому что директория Contracts явно не сюда, либо Interfaces, либо вообще без директории, добавить постфикс Interface

Зачем, когда из коробки существует createMany?