Какова цель хранилища, когда классы обслуживания могут делать то же самое?

Question

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

namespace App\ProjectName\Profile;

use App\User;

class AccountService
{
    private $userModel;

    public function __construct(User $userModel)
    {
        $this->userModel = $userModel;
    }

    public function detail()
    {
        $user = \Auth::User();

        return [
            'id'    => $user->id,
            'name'  => $user->name,
            'email' => $user->email,
            'keys'  => $user->keys,
        ];
    }

    public function addKey($name, $key)
    {
        return $this->userModel->keys()->create([
            'name' => $name,
            'key'  => $key
        ]);
    }
}

Я видел некоторый пример, подвергнутый рефакторингу еще дальше путем создания классов репозитория. что-то вроде UserController вводит данные, отправляет их UserCreatorService, который получает UserRepository который в свою очередь получает UserModel, Это выглядит UserCreatorService повторение UserRepository?

Answer 1

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

Однако Сервис и Репозиторий - это две разные вещи. Репозиторий - это обычная оболочка для модели, в которую вы записываете запросы в базу данных. IMO, вы не должны добавлять логику здесь, и единственная цель репозитория - захватить хранящиеся данные в базу данных. Преимущество репозиториев заключается в "простоте" переключения на другие системы баз данных.

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

Для получения дополнительной информации обратитесь к этому ответу.

Answer 2

От DDD (Domain Driven Design) ответственность за хранилище заключается в загрузке, хранении, изменении и удалении объекта в указанном хранилище данных (которое может быть или не быть базой данных - это может быть даже удаленный сервер или просто файл).

Сервис, с другой стороны, несет (или должен иметь) очень узкую ответственность за выполнение некоторой полезной деятельности. Каждый сервис создается отдельно, а затем внедряется в код на уровне приложения или выше, который действует как мост (паттерн Bridge). Этот подход оказался очень выгодным, потому что он позволяет управлять зависимостями между иначе несвязанным (несвязанным) кодом.

Эти два определения и происхождение понятий показывают, что они на самом деле очень разные вещи. По чистой случайности вы заметили, что хранилище и служба имеют явное совпадение, но это связано с деталями реализации или простым неправильным использованием. В определенных обстоятельствах их обязанности могут идти рука об руку (порождая сотрудничество), но они действительно являются ортогональными понятиями.

Кроме того, хранилища должны возникать из глубокого уровня (Persistance или DAL, Data Access Layer). С другой стороны, сервисы часто являются вертикальными или возникают на прикладном уровне.

Благодаря правильному наслоению различия между репозиториями и сервисами становятся еще более очевидными.

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

Я надеюсь, что мне удалось написать что-то, что проясняет некоторые идеи и не сбивает с толку.

Answer 3

Мой руководитель проекта сказал:

используйте шаблон репозитория для простого PHP.

используйте шаблон службы для проекта Laravel.

Я не знаю точной причины. но у него много знаний и опыта.