куда поместить вставку и получить логику запроса в слое или модели сервиса? - PullRequest
Новая
       11

куда поместить вставку и получить логику запроса в слое или модели сервиса?

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

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

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

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

public function store(Request $request)
    {

        DB::beginTransaction();
        try{
            $results = $this->transport_service->doLogic($request); //makes logic according to user data.
            if($results) {
                $storeData = Transport::storeTransportThisWay($results, $request); //then we use model's function..
            }
            DB::commit();

            return response()->json(['success'=>'Transport type  has been binded to column and its values successfully'], 200);

        }catch(\Exception $e){
            DB::rollback();
            return response()->json(['error'=>'Something went wrong, please try later.'], 500);
        }
    }

, поэтому в принципе я пишу любые запросы в модели.и любая бизнес-логика в сервисе.

Первый вопрос: хороший ли это подход?

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

Хороший пример будет высоко оценен.

1 Ответ

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

В вашем случае я бы рекомендовал следующую концепцию:

Поток данных: Request > Controller Action > Service > Repository > and back to the response

Контроллер (Действие) просто «делегирует» классу Service, берет результат и создает ViewData для визуализации ответа.

Пример 

public function __invoke(Request $request, Response $response, array $args): ResponseInterface
{
    $id = (int)$args['id'];

    $user = $this->userService->getUserById($id);

    $viewData = [
        'user' => $user,
    ];

    return $this->render($response, 'User/user-edit.twig', $viewData);
}

(Домен) Служба отвечает затак называемая «бизнес-логика» и обработка транзакций.Здесь вы также можете использовать пользовательский класс проверки для проверки запрошенной формы или данных API.

Пример 

namespace App\Domain\User;

use App\Domain\User\UserData;
use App\Domain\User\UserRepository;
use App\Domain\ApplicationService;

/**
 * Class.
 */
class UserService extends ApplicationService
{
    private $userRepository;

    public function __construct(UserRepository $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function getUserById(int $userId): UserData
    {
        // Add some fancy business logic here, validation, transaction handling etc.

        return $this->userRepository->getById($userId);
    }
}

(ориентированный на постоянство) Репозиторий отвечает только за «логику доступа к данным (связь с базой данных), например, запросы к базе данных (например, выбор, вставка, обновление, удаление).

Пример 

<?php

namespace App\Domain\User;

use App\Domain\User\UserData;
use App\Domain\ApplicationService;
use DomainException;

class UserRepository extends ApplicationRepository
{

    public function getById(int $id): UserData
    {
        // perform sql query here
        $user = ...

        if (!$user) {
            throw new DomainException(__('User not found: %s', $id));
        }

        return $user;
    }
}
...