Best Practice при работе с репозиториями в Laravel?

Question

[Влад]

Здравствуйте!

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

Правильно ли я мыслю:

1. В папке app мне нужно создать каталог Repositories
   
2. Если я работаю с пользователями, мне нужно создать подкаталог Users
   
3. В нем создать контракт репозитория и реализацию
   
4. В сервис провайдере забиндить все это дело
   
5. В контроллер в __construct подключать контракт и в приватную переменную $users принимать его
   

По различным источникам я так себе это представляю. Но также есть и вопросы:

1. Как все это смотрится с AR?
   
2. В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?
   
3. Правильно ли я размышляю вообще?
   

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

Answer 1

[D3lphi]

Да, по реализации все верно вы себе представляете.

Как все это смотрится с AR?

Откровенно скажу, с AR это смотрится хреново. В том смысле, что вы не используете основные "преимущества" (Да, да, в кавычках, потому что эти самые преимущества облегчают и ускоряют разработку, но никак не способствуют улучшению качества кода и его поддержке) этого паттерна.

В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

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

Правильно ли я размышляю вообще?

Да, по реализации все верно вы себе представляете.

Comments

[Влад]

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

Тогда от контрактов и биндинга придется отказаться? И инъектить в контроллер сам репозиторий?

[D3lphi]

Result007,

Тогда от контрактов и биндинга придется отказаться? И инъектить в контроллер сам репозиторий?

Что? Зачем?

[Влад]

D3lphi, Дошло что за бред написал. Извиняюсь

[Влад]

Но лично я бы так делать не стал.

Можно узнать почему?

[D3lphi]

Result007,
Не вижу в этом особого смысла.

1. Так как этот абстрактный репозиторий универсален, то код усложнится, он будет требовать "знаний" о модели Active Record.
   
2. Я предпочитаю писать методы в репозиторий по мере того, как мне они становятся нужны.
   

[Влад]

D3lphi, Большое спасибо!

Answer 2

[Дмитрий Евграфович]

Если у вас большая часть данных может быть взята с помощью eloquent - не стоит внедрять репозитории. Два года уже работаю над проектом, в котором в наследство были добавлены репозитории (все реализовано так, как у вас описано + как описал D3lphi), пришел к выводу, что это избыточный слой. В ларавел они хорошо выглядят разве что когда много сложных запросов и часто используется query builder. Но если все-таки решили, помните, что репозитории не должны отдавать из себя Eloquent модель.

Comments

[Artem Moseev]

А что они Репозитории должны отдавать?

[Дмитрий Евграфович]

Artem Moseev, объект, который не имеет возможности работать с базой данных (либо коллекцию с такими объектами). По сути только данные из модели.

Answer 3

[hakkol]

Для начала разберитесь для чего нужен репозиторий, вот на хабре писали хорошую статью https://habrahabr.ru/post/316836/ Чтобы выносить логику из контроллеров, используйте сервисы - https://laravel-news.ru/blog/tutorials/design-patt...

Comments

[Влад]

Спасибо за статьи =)

Answer 4

[Иван]

Как все это смотрится с AR?
В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

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

Comments

[AlikDex]

Чтобы был, очевидно же =)
Им видители необходимо натянуть репозиторий на АР ))