Какую концепцию структурирования приложения на Laravel лучше использовать?

Question

[Vasyl Fomin]

Какую концепцию структурирования приложения на Laravel лучше использовать для начинающих для не очень сложных проектов? Репозитории или Сервисы . О репозиториях, в отзывах есть много отрицательных. О сервисах информации меньше.
Или может есть еще что то?

Answer 1

[Вячеслав Плиско]

Репозиторий это тоже сервис, RepositoryService. Оба ваши примера идентичны, и просто прячут вашу Eloquent модельку внутри себя, при этом спокойно её возвращают в return. Оба автора делают это без осознания зачем это надо и не получают никакого профита от этих телодвижений.

Единственное что можно вынести из примеров - не использовать eloquent методы в контроллере, их нужно выносить в отдельный сервис или как минимум в отдельный метод модели. Например, у модели Post добавили бы метод findBySlug() или createCoupon($code, $amount, $maxRedemptions), этого достаточно было бы для инкапсуляции и последующего расширения. (хотя не решает проблему с торчащим наружу AR, но это уже другой вопрос)

Comments

[Vasyl Fomin]

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

[Vasyl Fomin]

Вот нашел пример реализации (https://github.com/bestmomo/laravel5-3-example) репозитория но без использования интерфейсов. Посмотрите пожалуйста, можно ли использовать концепцию для своих проектов?

Answer 2

[Tesla]

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

А сервисный слой в данном случае всего лишь способ разгрузить контроллеры и избежать дублирования кода. То, что будет у вас между контроллером и моделью. Пример реализации: https://laravel.com/docs/5.3/queues#creating-jobs создаем Job, выполняющий конкретную узкую задачу, и запускаем его через диспетчер

Comments

[Vasyl Fomin]

Ну так проще уже репозиторий сделать чем использовать Job. Да и, как мне кажется, Job здесь не лучший вариант для создание методов между контроллером и моделью

[Tesla]

foommiinn: Job - это сервис, а не репозиторий. Например, вам нужно не просто создать запись, а еще добавить связи с изображениями в БД, создать новые теги, добавить связи с тегами, отправить уведомления подписчикам и еще много всего. Чтобы не раздувать контроллер, все эти действия выносите в отдельные Jobs и по цепочке их запускаете.

[Vasyl Fomin]

Вот нашел пример реализации (https://github.com/bestmomo/laravel5-3-example) репозитория но без использования интерфейсов. Посмотрите пожалуйста, можно ли использовать подобную концепцию для своих проектов?

[Tesla]

foommiinn: Вот это я считаю плохими репозиториями. Они либо не содержат ничего, либо перегружены, выполняют слишком много лишнего (репозиторий блога создает теги); куча очень узкоспециализированных методов одноразового применения. Разумеется, есть сторонники таких репозиториев, но я больше склоняюсь к мнению в этой статье https://habrahabr.ru/post/248505/ Имхо, если вы используете Eloquent, который сам чего только не умеет, нет никакого смысла оборачивать его репозиторием.

[Vasyl Fomin]

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

Answer 3

[Павел Тузов]

Мне кажется, что данные подходы не исключают друг друга. Репозиторий нужен для складирования запросов к модели, а сервисный слой для более сложной логики, которая неуместна в контроллере. И то, и другое уместно, если Вы понимаете, для чего нужен каждый шаблон проектирования.

Comments

[Vasyl Fomin]

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