@Result007
P|-|P

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

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

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

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


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

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


Большое спасибо за внимание и будущую помочь. Не сочтите вопрос банальным или тупым, всего лишь хочется разобраться, чтобы избежать ошибок в будущем!
  • Вопрос задан
  • 2888 просмотров
Решения вопроса 1
@D3lphi
Да, по реализации все верно вы себе представляете.

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

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

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

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

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

Да, по реализации все верно вы себе представляете.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Если у вас большая часть данных может быть взята с помощью eloquent - не стоит внедрять репозитории. Два года уже работаю над проектом, в котором в наследство были добавлены репозитории (все реализовано так, как у вас описано + как описал D3lphi), пришел к выводу, что это избыточный слой. В ларавел они хорошо выглядят разве что когда много сложных запросов и часто используется query builder. Но если все-таки решили, помните, что репозитории не должны отдавать из себя Eloquent модель.
Ответ написан
@hakkol
Для начала разберитесь для чего нужен репозиторий, вот на хабре писали хорошую статью https://habrahabr.ru/post/316836/ Чтобы выносить логику из контроллеров, используйте сервисы - https://laravel-news.ru/blog/tutorials/design-patt...
Ответ написан
IvanTheCrazy
@IvanTheCrazy
Как все это смотрится с AR?
В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы