Всем привет. Подскажите, если знаете где можно посмотреть примеры структуры

в laravel проектах. Очень редко получается найти что то кроме - логику в Service, общение с базой в Repository. Мб у кого то есть ссылки на git репозитории или полезные статьи?

Яб тоже посмотрел, но тут кто во что горазд...

А может это и есть структура ларавель приложения?

Общение с БД через репозиторий это очень редко о проекте Ларавель)

честно говоря вообще не согласен с этим. В каждом рабочем проекте используется репозиторий. Если вы чаще делаете по другому - поделитесь)

А зачем репозиторий для Eloquent? Или вы в каждом рабочем проекте свайпаете его на что-то другое?

репозиторий это не data maper если что. Задача репозитория - вынести запросы в отдельный класс, чтобы а) иметь возможность их использователь в разных местах б) Создать прослойку для сокращения кода в Логике/контроллере . Или вы запросы с фильтрацией и пагинацией прямо в контроллере вызываете и каждый раз прописываете запрос?

ну типо синг респонсибили тоже

+

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

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

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

Porto. Laravel apiato читайте

Так у вас же AR, модель и есть отдельный класс для запросов. Нет?

Ну мы сидим на ларе, вы не переходите например на доктрину, то есть менять “способ работы с БД” не собираетесь. Первый вопрос, тогда зачем делать еще один уровень “абстракции”? Вы используете далее модели от Лары, создете “сервис” для логики, и там вам нужно получить юзеров с ролью (как писали потом пример). В сервисе вы вместо вывозва двух методов от модели, “зовете” репозиторий, и потом через него эти два метода вызываете. Но что мешало вызвать их там же? Нужно переиспользовать? Давайте вынесем их в отдельный класс работы с юзерами, или отдельный метод, если переиспользуем тут же. Вы не планируете менять далее ORM, работаете с одной, проект пишете не под OpenSource, где в теории кто-то захочет поменять ORM, так зачем репозиторий? Что бы вписать в список регалий проекту, или так в книжках пишут, что нужно использовать много паттернов?

Но я не писал о получении юзеров с ролью. Я писал что проблема скоупа, что для юзеров к которых есть методы для конкретных ролей (банальный пример - только менеджеру нужен список работников) всеравно этот метод будет в модели юзер. Таким образом модель станет гипертолстой уже на середине проекта. Чет вы прям меня очень не так поняли) Но тут еще прикол - вы предлагаете вынести методы в отдельный класс. Но в репозитории они уже в отдельном классе)

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