Иначе сколько у тебя в контроллере зависимостей будет

Они должны быть связаны быть через единый сервис

они не должны быть связаны

Иначе сколько у тебя в контроллере зависимостей будет

смотря что ты под контроллером подразумеваешь. Обычно там 1 сервис

Ну даже в статье там userservice он работает с юзерами

Ты бы его разбил на createuser и ТП?

Ты бы его разбил на createuser и ТП?

конечно

конечно

Ты понимаешь что сервис своего рода фасад.. а ты хочешь сделать куча связей в системе

в контроллере у тебя будет actionCreateUser(CreateService $service) $servise->createUser($data)

Ты понимаешь что сервис своего рода фасад.. а ты хочешь сделать куча связей в системе

Сервис не фасад

Ты понимаешь что сервис своего рода фасад.. а ты хочешь сделать куча связей в системе

каких связей? сервис далеко не фасад

в контроллере у тебя будет actionCreateUser(CreateService $service) $servise->createUser($data)

Почему создавать юзера не может единый сервис который управляет юзерами

Почему создавать юзера не может единый сервис который управляет юзерами

SRP

Вообще юзер не создаётся а регистрируется в контексте бизнес логики

каких связей? сервис далеко не фасад

Обоснуй

Чем сервис не фасад

Чем сервис не фасад

ты понимашь что такое фасад?

именно шаблон проектирования?

Чем сервис не фасад

Ничто не фасад кроме фасада же)

именно шаблон проектирования?

Именно он

окей, вот, например есть такой юзкейс есть пост, у него из "не родных" пропертис есть категории, теги и изображение категории установлены статически, т.е. прилетает id а теги динамически, могут создаваться новые, при добавлении статьи, т..е. прилетает массив строк собственно что нам по итогу нужно сделать 1) сохранение изображения (обрезка, вотермарк, сжатие или еще что то) 2) нормализация тегов, т.е. из этого массива строк нужно получить массив идентификаторов 3) все это вместе сохранить можешь пожалуйста, описать какие в этом примере будут сервисы, репозитории и что где будет находиться и вызываться это очень здорово помогло бы

Почему создавать юзера не может единый сервис который управляет юзерами

Может но не обязан.

Именно он

что такое сервис тогда в твоем понимании ?

Может но не обязан.

userService.register.. разве не так должно быть?

что такое сервис тогда в твоем понимании ?

Модуль который инкапсулирует бизнес логику

Модуль который инкапсулирует бизнес логику

всю логику приложения?

всю логику приложения?

Ну не один сервис, каждый сервис за какую то логическую задачу отвечает

Например расчет скидок каких нибудь или заказ товара

окей, вот, например есть такой юзкейс есть пост, у него из "не родных" пропертис есть категории, теги и изображение категории установлены статически, т.е. прилетает id а теги динамически, могут создаваться новые, при добавлении статьи, т..е. прилетает массив строк собственно что нам по итогу нужно сделать 1) сохранение изображения (обрезка, вотермарк, сжатие или еще что то) 2) нормализация тегов, т.е. из этого массива строк нужно получить массив идентификаторов 3) все это вместе сохранить можешь пожалуйста, описать какие в этом примере будут сервисы, репозитории и что где будет находиться и вызываться это очень здорово помогло бы

описание этого, кажется и @wentixon тоже поможет

Ну не один сервис, каждый сервис за какую то логическую задачу отвечает

за какую? задачу отвечает мой сервис FooService?

userService.register.. разве не так должно быть?

У меня может быть отдельно UserBuilder или UserRegistrator. А общего сервиса может или не быть или он заниматься может только другими вещами без регистрации

за какую? задачу отвечает мой сервис FooService?

Ты издеваешься надо мной? От куда я знаю

Например расчет скидок каких нибудь или заказ товара

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

Ты издеваешься надо мной? От куда я знаю

А вот этот сервис CreateUserService? :)

У меня может быть отдельно UserBuilder или UserRegistrator. А общего сервиса может или не быть или он заниматься может только другими вещами без регистрации

А не лучше поручить общему сервису делегировать работу таким вот подсервиспм и общаться через него?

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

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

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

затем что он может содержать огромное кол-во логики, но он отвечает только за создание поста

его зависимости не влияют на обновление поста или удаление

А не лучше поручить общему сервису делегировать работу таким вот подсервиспм и общаться через него?

Зависит от количества таких подсервисов и от реальной их необходимости реиспользования и от объема кода в них и так далее

При чем почему вообще должен быть сервис который позволяет создавать юзера? Юзер регистрируется а не создается

зайчики, прыгните к моему сообщений плиз

?

При чем почему вообще должен быть сервис который позволяет создавать юзера? Юзер регистрируется а не создается

это смотря где ты и что делаешь. Через консоль например может и создаваться

Окей.. а как вы с бд работаете в сервисах?

Eloquent нахер я так понимаю?

При чем почему вообще должен быть сервис который позволяет создавать юзера? Юзер регистрируется а не создается

А вот и не обязательно. У меня регистрацит может не быть я именно создаю юзера. Это уже семантика именования зависящая от реального приложения.

И репозитории за сервисами прикидывать тогда?

В пзду репозитории с ар

зайчики, прыгните к моему сообщений плиз

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

В пзду репозитории с ар

Ну доктрин же значит

Согласен что ар с репозиториями это дерьмо

Ну доктрин же значит

в чем разница то?

в чем разница то?

Разница с чем

Ну доктрин же значит

Или просто ар и мб где нужно квери обжекты

как orm влияет на твою логику приложения?

как orm влияет на твою логику приложения?

Речь о том чтобы выкинуть елоквент

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

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

Речь о том чтобы выкинуть елоквент

зачем ее выкидывать?

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

ты внимательно читай. Вот что у тебя в котроллере "Пришел запрос, я создаю пост, даю ответ"

все

так прямо и пиши

зачем ее выкидывать?

Ты с репозитории не работаешь?

Все эти споры о архитектуре абстрактны и бессмысленны. Нет правильной архитектуры абстрактно. Есть хорошие приемы. И всё. А архитектура просто должна быть. А приемы должны быть оправданны

Ты с репозитории не работаешь?

ммм... работаю ar это и есть репозиторий

ar репозиторий????

ar репозиторий????

а ты как думал? :)

ar репозиторий????

Ну в целом да, оно все в одном

ar тот что active record?

ERROR: S client not available

В этом их и проблема

ar тот что active record?

Ага

так а как ar переводить на апи или массивы например

так а как ar переводить на апи или массивы например

Api Recource читай в доке

ar тот что active record?

вот почитай, интересное https://gist.github.com/fesor/d84451fc6cf00ea62ca5

Бегите глупцы дух фессора в треде!

А куда лучше сложные sql запросы помещать?

в репозиторий ?

вот почитай, интересное https://gist.github.com/fesor/d84451fc6cf00ea62ca5

Очень крутой чел, он в симфони чатике сидит )

в репозиторий ?

То есть в ар?

в репозиторий ?

Этот мел не мел)

в репозиторий ?

не надо их туда

лучше для них сделать отдельные Query Objects

Этот мел не мел)

ну а куда ты их еще денешь ?

лучше для них сделать отдельные Query Objects

эт че за ?

ну а куда ты их еще денешь ?

Все в модель запихнуть

ну, хз. Мне репозиторий больше нравится

окей, допустим я признал, что ar является и репозиторием, как использовать модель в качестве оного?

подскажите пакет для авторизации через соц сети

Кто нибудь юзал geonames? Никак не могу найти у них на сайте описание возвращаемых полей

подскажите пакет для авторизации через соц сети

socialite

ну, хз. Мне репозиторий больше нравится

особенно когда в нем 100+ методов :)

socialite

там есть российские соц сети?

особенно когда в нем 100+ методов :)

три по 33+ ?

там есть российские соц сети?

не помню

ну, хз. Мне репозиторий больше нравится

Ну я тоже согласен что им там самое место, но ар с репозиториями и это та ещё затея

там есть российские соц сети?

читай доку

читай доку

ну я увидел что нет, поэтому и спрашиваю

Да можно в репозиторий просто понимать что это не репозиторий.

ну я увидел что нет, поэтому и спрашиваю

плохо смотрел

Ну я тоже согласен что им там самое место, но ар с репозиториями и это та ещё затея

да почему же. Работает. Что такое репозиторий ? Просто класс, куда ты пихунишь запросы из элоквента

Я с телефона не успеваю за вами. Леваю

и потом инжекть его куды душе угодно