Нужен ли репозиторий для Eloquent??

Question

[glebvvs]

Всем примет. Недавно прочел несколько статей на тему реализации паттерна репозиторий в фреймворке Laravel. Как реализовать сам паттерн мне стало ясно, но абсолютно непонятно имеет ли смысл этот паттерн, если во всех примерах в качестве точки доступа к БД используют Eloquent?

Я понимаю смысл создания репозитория для QueryBuilder. Это как раз таки позволит отделить логику запросов от бизнес логики, располагаемой в моих сервисах, но нужно ли это при Artive Record? Ведь мне казалось, что модели Eloquent уже в принципе сами по себе выполняют что-то вроде репозитория? То есть они имеют свой базовый удобный интерфейс, который можно расширять локальными и глобальными скоупами. И если это можно делать, но непонятно зачем тогда нужен отдельный слой, который будет делать то же самое...

Еще говорят, что это позволит менять тип хранения данных. Но мне это тоже не совсем ясно. Ведь если я буду использовать ORM, то она определеет в какой-то степени формат вывода данных. Например смежные таблицы Eloquent являются вложенным объектами в объект. То есть даже при выводе массива, мы получим вложенность, которая будет несовместима даже с QueryBuilder, а адаптация биг даты и подведение ее к какому-то формату вывода это неблагодарное дело. А если думать о Redis, то большинство проектов в принципе нельзя перенести на нереляционные БД.

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

Comments

[Alex Wells]

*ИМХО*

Я не профи, и все же: в случае Eloquent - нет, не стоит. Лично я использую архитектуру Porto, и вместо репозиториев использую "таски" - классы, выполняющие ровно одно действие. Для простоты можно представить, что каждый таск - отдельный метод в сервисе, в обычной сервисной архитектуре. Так вот, если правильно ее использовать, в конечном итоге у вас точно будет несколько тасков, которые только то и делают, что проводят манипуляции с БД.

1) нету смысла делать таск, который инжектит репозиторий а потом просто вызывает метод из репозитория. Почему бы не использовать сам таск для хранения логики?
2) иногда приходится писать некую логику с киданием эксепшенов прямо внутри транзакций (функции, которая в DB::transaction() передается). Например, есть таск "отнять у юзера $user $amount денег", и я бы хотел получить InsufficientFundsException в случае, если у юзера не хватает их. Это не совсем задача репозитория, но в тоже время мы никак не сможем вынести оттуда эту логику..

На счет "менять тип данных" - нет, оно то может выйти (на выходе - интерфейсы, на входе - отдельные входные переменные), но я не вижу смысла. Если уж вам так захочется перейти на Doctrine (единственный доступный вариант), то отрефакторить проект, наверное, будет проще, чем каждый раз описывать интерфейсы, использовать репозитории и так далее. Не стоит оно того.

Пока что репозитории мне еще ни разу не пригодились - лучше правильно строить логику и разделять ее на методы (таски).

*ИМХО*

[glebvvs]

То есть вы делаете классы, в которых всего один публичный метод реализующий отдельную логическую операцию проекта? Я верно понял?

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

Answer 1

[Tesla]

Соль в том, что если вы на 100% в точности не уверены, что паттерн репозиторий вам нужен, значит он вам не нужен. В противном случае вы получите лишний слой абстракции, гору копипасты и дублирование того же самого Eloquent.

Советую мастеркласс по DDD (во второй части про репозиторий), объясняет для чего нужны многие вещи.

Comments

[NikolayAlb]

Воспользуюсь возможностью задать вопрос. А куда подобную логику стоит инкапсулировать? В репозиторий - да вроде нет, он не совсем для этого, в саму модель - тоже бред. Да и вообще в целом не могу понять куда прописывать логику подобную? (Когда нужно произвести что-то немного больше, чем просто запись в БД) Возможно создать Ивент для этого, но тоже сомнительно как-то.

protected $uploadService;

    public function __construct(User $user, FileUploadContract $uploadService)
    {
        $this->user = $user;
        $this->uploadService = $uploadService;
    }

    public function updateUserImage(UploadedFile $image)
    {
        $oldImageName = $this->user->profile_image;

        $newImageName = uniqid("", false) . '.png';
        $this->user->profile_image = $newImageName;

        try {
            DB::transaction(function() {
                $this->user->update();
            });
            $this->uploadService->upload($image, $newImageName, $oldImageName);
        } catch (Exception $e) {
            abort(503, $e->getMessage());
        }
    }

[Tesla]

NikolayAlb, например, в \App\Services\User\UpdateImageService или \App\Services\UserService. Можно зарегистрировать его в сервис-контейнер, передать зависимости, и в контроллере вызывать через сервис-контейнер.

[NikolayAlb]

Tesla, таким образом нормально?

class UserService extends UserServiceContract
{
    protected $user;
    protected $uploadService;
    //Конструктор с определением $user b $uploadService вшит в абстрактный класс UserServiceContract вот так:
/*
public function __construct(User $user, FileUploadContract $uploadService)
    {
        $this->user = $user;
        $this->uploadService = $uploadService;
    }
*/
    public function updateUserImage(UploadedFile $image): void
    {
        $oldImageName = $this->user->profile_image;

        $newImageName = uniqid("", false) . '.png';
        $this->user->profile_image = $newImageName;

        try {
            DB::transaction(function(){
                $this->user->update();
            });
            $this->uploadService->upload($image, $newImageName, $oldImageName);
        } catch (Exception $e) {
            abort(503, $e->getMessage());
        }
    }
}

Всё это дело регистрируется в контейнере вот так:

app()->bind(UserServiceContract::class, function($app, $parameters) {
    return app()->makeWith(UserService::class, $parameters);
});

app()->when(UserService::class)->needs(FileUploadContract::class)
    ->give(function() {
        return new AvatarUploadService(config('images.user_avatar_dir'));
    });

И в конечном итоге в контроллере всё используется вот так:

public function postUserProfileImage(UserUpdateImageForm $request)
{
    $userService = app()->makeWith(UserServiceContract::class, ['user'=>auth()->user()]);
    $userService->updateUserImage( $request->file('profile_image') );

    return redirect()->back();
}

[Tesla]

NikolayAlb, UserServiceContract должен быть интерфейсом. На вызов этого контракта (интерфейса) из сервис-контейнера вы биндите конкретную реализацию UserService.

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

Если нужно вынести какую-то общую часть всех классов в абстрактный класс, то назовите его AbstractUserService.

[NikolayAlb]

Tesla, Понял, спасибо.

[NikolayAlb]

Tesla, Слушай, а если логика не совсем отстраненная, как в виде загрузки картинки. Например при создании какой-то модели нужно совместно с непосредственной записью полей и сохранением модели - загрузить картинку из поля на сервер? При удалении модели - соответственно и с диска файл удалить и всё в таком духе? Куда подобные вещи тогда инкапсулировать? Вешать наблюдателя на creating/deleting и в нем уже ловить файл, производить с ним действия и дальше передавать запрос?

[Tesla]

NikolayAlb, да

Answer 2

[Vasyl Fomin]

Вот ещё статья https://m.habr.com/post/316836/
Я лично отказался от репозитория с eloquent

Answer 3

[Adelf]

Eloquent прекрасно выполняет свои задачи простой и более-менее эффективной ORM для проектов с CRUD и около таких.
Разумеется частенько нужны запросы посложнее и их выделяют либо в скоупы в самой модели либо в отдельные классы, которые билдят запросы.
Когда задачи становятся еще сложнее, когда нужно уже делить всю нашу модель на read and write части, Eloquent уже начинает подбешивать :) Плюс невозможность отделить логику класса модели от логики её хранения в бд начинает напрягать на любых моделях сложнее одной строки в базе. В итоге в тех проектах, в которых мы хотим отделять Domain логику от всего остального(в том числе базы данных) намного выгоднее отойти от него.
Все эти репозитории нам нужны как раз для этого, чтобы абстрагироваться и отделить логику хранения обьектов доменной логики где-либо. А с элоквентом это практически невозможно. Я это подробно буду разбирать в книжке, которую тут уже отрекламировали - https://leanpub.com/architecture-of-complex-web-ap...

Выделять же классы для некоего query building - вполне нормально для проектов с Eloquent. Вот только не увлекаться желательно. Иногда люди мучаются страшно с этими элоквентовскими билдерами, тогда, когда проще банально написать raw SQL запрос. Обычно это касается всяких отчетов, где много разной интересной агрегации с группировками и т.д.

Answer 4

[Andrey Helldar]

Eloquent - это уже есть репозиторий для QueryBuilder

Comments

[glebvvs]

вот и мне так кажется, но все равно в опенсорсных проектах порой вижу эту лишнюю ненужную абстракцию репозитория поверх орм...)

[Andrey Helldar]

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

Answer 5

[Александр Талалаев]

Чет вы сумбурно написали и смешали разные вещи.
В ларавел есть отдельно удобные инструменты/обертки для работы с базой данных, и отдельная вещь это Eloquent ORM по строенная по принципам (анти или нет) патерна ActiveRecord.
Так вот, значит обертки над базой данных ты используешь и реализуешь/используешь удобный тебе подход/патерн к организации моделей. В целом, я советую уходить от Eloquent если проект будет развиваться в перспективе и/или если его будут вести несколько человек, так как начинается брожения моделей-свойств и и методов Eloquent по проекту, что в конце концов приводит к усложнению отладки, развития изменения/добавления редактирования свойств и тд и тп. Конечно если проект простенький, без супер логики и ты знаешь что дальше будет все просто, то можно не парится.
Ну и советую изучить и прочитать этот коммент на тостере напрямую на эту тему:
https://toster.ru/answer?answer_id=1127442#answers...

Comments

[Andrey Helldar]

Ага. Уходи от eloquent и юзай чистый sql в 2к18 :)
Работаю над четырьмя крупными проектами в команде из трёх человек. Элоквент никак не мешает. Наоборот даже во многом спасает ситуацию, начиная с того что у тебя есть конкретная модель с конкретными свойствами. А если кому-то надо ее расширить, это делается очень легко.

[Александр Талалаев]

Helldar, ну и где я написал что нужно отказаться от Eloquent в пользу чистого sql? Я только отметил что можно использовать другую ORM или написать свой подход и спокойно юзать QueryBuilder он никак не завязан на Eloquent.

[Andrey Helldar]

Александр Талалаев, вчитайся в свои же слова:

В целом, я советую уходить от Eloquent если проект будет развиваться в перспективе и/или если его будут вести несколько человек, так как начинается...

Вот именно здесь ты это и сказал.

[glebvvs]

Helldar, ну на самом деле везде рекомендуют ActiveRecord юзать для мелких и средних проектов. так что в его словах есть доля истины...

[Andrey Helldar]

glebvvs, Laravel использует Eloquent вместо AR. Это типа конкуренты.

[Andrey Helldar]

glebvvs, вот здесь один российский сеньор книгу свою пишет про хайлоад проекты на ларе, в одном из которых он сам работает: https://leanpub.com/principles-of-creating-big-app...

[Voll .]

Helldar, ссылка битая

[Andrey Helldar]

Voll ., вероятно автор ее скрыл, т.к. он ещё пишет ее.
Вот линк на автора: https://t.me/Adelf32

[Adelf]

https://leanpub.com/architecture-of-complex-web-ap... вот верная линка. Спасибо за пиар :)