Принцип Единой Ответственности (SRP) на примере Laravel

[@trawl]

А должен ли OrderService::create() знать, что такое Request?

По-моему, суть контроллера получить запрос, вынуть из него параметры, и эти параметры уже передать в сервис, а ответ сервиса преобразовать в абстракцию http ответа и вернуть её.

Сервис же может использоваться и в консольной команде.

[@Palych_tw]

а $request->all() — это не целиком объект http запроса и не объект класса Request, а массив из тела запроса прошедший валилацию

[@trawl]

Да там в примерах кода вообще лютая путаница…
Я, когда писал комментарий, апеллировал к этому фрагменту:

public class OrderService
{
    public function create(Request $request)
    {
        // Создание заказа
        // Резервирование товаров

        $sms = new RuSms();
        // Устанавливаем номер и текст сообщения и уникальный идентификатор приложения 
        $sms->send($number, $text, $appId);
     }
}

[@Palych_tw]

Ага. Сначала передается в сервис обычный массив

$this->service->create($request->all());

Потом ожидается в этом методе Request

public class OrderService
{
    public function create(Request $request)
    {
        // Создание заказа
        // Резервирование товаров

        $sms = new RuSms();
        // Устанавливаем номер и текст сообщения и уникальный идентификатор приложения 
        $sms->send($number, $text, $appId);
     }
}

А потом вообще в сервисе метод create ничего не принимает и ничего не возвращает.

public function create(): void
    {
          // Создание заказа

          // Резервирование товаров

          $this->sms->send($nubmer, $text);
    }

Новичок здесь запутается полностью)

[@Compolomus]

Нормально так интерфейс наследовали, поправить бы надо пример

[@trawl]

class OrderController extends Controller
{
    protected $service;

    public function __construct(OrderService $service)
    {
        $this->service = $service;  
    }

    public function create(OrderRequest $request)
    {
        // Не боитесь коллизий параметров? 
        // Например, product_id может оказаться и в GET, и в POST. 
        // Какое значение вернёт метод $request->all()?
        // Это точно будет то значение, которое нужно?
        // Используйте лучше $request->query() или $request->post()
        $this->service->create($request->all());

        // Что за $order, откуда он берётся? Наверное его возвращает сервис, 
        // но интерпретатор не настолько сообразителен.
        return response()->json($order, 201);
    }
}

[@greatkir]

Так где же разбор SRP на примере представленного кода?
Зашел почитать статью ради этого, но заголовок ввел в заблуждение

[@vism]

Передавать чистый массив в Сервис это то еще извращение.
Передевать Request в сервис это то еще нарушение SRP (Как ж его использовать из консоли? :) )

Хотя бы про DTO упомянули, тем более что под Ларавель шикарный пакет есть.
Я конечно понимаю, что часто DTO может быть излишнем и достаточно FormRequest в тандеме с этим плагином plugins.jetbrains.com/plugin/13441-laravel-idea
Но это ведь статья не о допущениях

Вобщем кто реально про SRP и сервисы почитать желает, лучше эту книгу посмотрите
github.com/adelf/acwa_book_ru

[@Veterinar]

Поделитесь пожалуйста шикарным пакетом DTO для laravel, спасибо.

[@vism]

github.com/spatie/data-transfer-object

[@Fortop]

Передевать Request в сервис это то еще нарушение SRP (Как ж его использовать из консоли? :) )

А в чем проблема-то создать реквест в консоли-то?
Несмотря на то, что это ларавель, но в нем упоролись еще не окончательно.

Поэтому у вас всегда есть возможность

Request::create()

И почему же это нарушение SRP?

[@Adelf]

Т.е. для вас совершенно нормально создать объект, в котором информация о куках, сессии и т.д. прям в консоли, чтобы имитировать вызов веб-контроллера? Никаких возможных проблем не приходит в голову?

[@Fortop]

Дважды перечитал ваш текст и не нашел в нем ответ на мой последний вопрос.

Вы же на него хотели ответить?

[@Stasgar]

Следовать SRS в Laravel это в целом сложно и для опытного разработчика, не говоря уже о новичке, вот некоторые моменты, которые сходу приходят на ум:

• Request (а точнее FormRequest) — помимо непосредственно хранилища атрибутов сущности «запрос» также отвечает и за авторизацию запросов и за их валидацию
• Фасады — глобально доступные объекты (часто синглтоны), которые используются в коде без явных пробрасываний с DI
• Eloquent — если углубиться — достаточно монструозная конструкция с кучей магических связей с квери билдером и другими вещами, не относящимися к AR сущности

П.с. это не камень в огород Laravel, я сам использую этот прекрасный фреймворк для многих проектов, это скорее то, что каждый новый разработчик должен понимать. Естественно это всё сделано для удобства и простоты использования и ИМХО в некоторых случаях оправданно и при желании большинство таких штук обходятся в правильном направлении (например можно использовать Policy для авторизации запросов, FormRequest только для валидации, фасады инжектить в контроллеры и т.д.). Это не плохо, что фреймворк дает такое разнообразие возможностей. Но все же архитектура лары нарушает достаточно много книжных принципов, в том числе и SOLID.