Pull to refresh

Comments 14

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


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


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

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

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


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

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

Ага. Сначала передается в сервис обычный массив
$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);
    }


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

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

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);
    }
}
Так где же разбор SRP на примере представленного кода?
Зашел почитать статью ради этого, но заголовок ввел в заблуждение
Передавать чистый массив в Сервис это то еще извращение.
Передевать Request в сервис это то еще нарушение SRP (Как ж его использовать из консоли? :) )

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

Вобщем кто реально про SRP и сервисы почитать желает, лучше эту книгу посмотрите
github.com/adelf/acwa_book_ru
Поделитесь пожалуйста шикарным пакетом DTO для laravel, спасибо.
Передевать Request в сервис это то еще нарушение SRP (Как ж его использовать из консоли? :) )


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

Поэтому у вас всегда есть возможность
Request::create()

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

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

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


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

Articles