Должен ли я использовать сервис для каждой функции каждого контроллера или работать с моделями непосредственно в контроллере? - PullRequest
Новая
       37

Должен ли я использовать сервис для каждой функции каждого контроллера или работать с моделями непосредственно в контроллере?

0 голосов
/ 25 декабря 2018

У меня такой тип ситуаций, у меня есть контроллеры, например, AuthController с функциями регистрации и входа в систему, у меня есть служба под названием AuthService, здесь я реализую функции, в которых у меня есть вся логика и связь с базой данных.все, что я делаю в контроллере, это $ auth_service-> register ($ request), а затем служба аутентификации делает все, возвращает объект ответа, а затем в контроллере я возвращаю этот объект как Json.поэтому у меня нет красноречивых функций в контроллере, нет бизнес-логики, только 3-4 строки кода.Это хорошая практика?например, если мне нужна только функция Modell: all () в контроллере, я должен использовать сервисную функцию даже для этого небольшого куска кода, в противном случае у меня будет структура, в которой я иногда использую сервисы, а иногда нет.Также, когда я внедряю класс обслуживания в контроллер, я также внедряю все полезные модели (иногда другие сервисы) в этот сервис, если в одном контроллере иногда я использую сервис, а иногда работаю с моделями напрямую, то получается, что я внедряю модель в сервис ив контроллере (впрыскивание одной и той же модели два раза).так что я должен продолжать делать это и использовать сервис для каждого контроллера каждой функции?Я имею в виду, какой путь будет лучше и почему?

это функция регистра моего контроллера аутентификации: 

protected $auth_service;

    public function __construct(AuthService $auth_service){
        $this->auth_service  = $auth_service;
    }

public function registerUser(UserRegisterRequest $request){
        $registerUser = $this->auth_service->registerUser($request);
        return response()->json($registerUser, 200);
    }

, а это контроллер языка: 

protected $language;

    public function __construct(Language $language){
        $this->language = $language;
    }

    /**
     * Display a listing of the resource.
     *
     * @return \Illuminate\Http\Response
     */
    public function index()
    {
        $languages = $this->language->getAllLanguage();
        return response()->json(['data'=>$languages], 200);
    }

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

1 Ответ

0 голосов
/ 25 декабря 2018

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

Например, инфраструктура Symfony больше не является MVC, потому что традиционным способом является создание сервисов, которые взаимодействуют с базой данных, а затем их внедрение в контроллер.работы на данный момент.

Когда эти услуги могут быть полезны?

Хорошо, учтите, что у вас есть несколько контроллеров, для которых вы хотите поделиться бизнес-логикой.Затем вы просто создаете сервис и внедряете этот сервис в несколько контроллеров.

Как вы можете повторно использовать логику с использованием чистого MVC?

Ну, вы можете просто вызвать метод контроллера из другого метода контроллера.

Что я предпочитаю?

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

  • код более структурирован
  • вы можете начать следовать принципам SOLID * Контроллер 1020 *
  • не имеет никакого бизнес-логика * Контроллер 1022 *
  • взаимодействует только с сервисным уровнем
  • бизнес-логика больше не зависит от контроллера
  • бизнес-логику можно легко перенести в любую php-среду
  • вы можете внедрять сервисы внутри сервисов и таким образом повторно использовать логику
...