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

но чаще всего мне надо работать с объектом. И получается, что я сначала получаю переменную $rateService. Затем в другую переменную получаю $currentRate = $rateService->getRate(); и потом уже работаю с $currentRate. Почему бы не инжектить ее сразу, если есть такая возможность? Или я что-то неправильно понял?

но чаще всего мне надо работать с объектом. И получается, что я сначала получаю переменную $rateService. Затем в другую переменную получаю $currentRate = $rateService->getRate(); и потом уже работаю с $currentRate. Почему бы не инжектить ее сразу, если есть такая возможность? Или я что-то неправильно понял?

ну вот видишь, сам о писал проблему. Сервис должен вернуть тебе готовые данные. А ты громоздишь логику в контроллере. Сделай сервис который вернет тебе просто готовые данные, и сам у себя там разберется что такое $currentRate. Биндинг переменной не очень тебе подойдет потому что переменная должда быть инициализированная до биндинга. Т.е. тебе на любой запрос придется рассчитывать $rateService->getRate();

$rateService->getRate(); - возвращает нужные данные. В контроллере нет дополнительной логики.

$rateService->getRate(); - возвращает нужные данные. В контроллере нет дополнительной логики.

т.е. ты эти данные сразу во view передаешь view()->with('rate', $rateService->getRate()) ?

т.е. ты эти данные сразу во view передаешь view()->with('rate', $rateService->getRate()) ?

не всегда. Иногда эти данные (модель) надо привзязать к другим моделям при сохранении, или сравнить с чем-то. Ну или если используется в другом сервисе, то на основе этих данных провести доп вычисления

не всегда. Иногда эти данные (модель) надо привзязать к другим моделям при сохранении, или сравнить с чем-то. Ну или если используется в другом сервисе, то на основе этих данных провести доп вычисления

вот, это все бизнес логика, когда ты начинаешь задумываться о том что следующиему сервису надо получить данные, а что будет если getRate не вернет ничего, или кинет эксепшен и так далее

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

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

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

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

нет, ты кидаешь их в сервис, и он сам определяет хватает для него всего или нет, если нет, то сам и запросит

это его дело, он должен думать

в контроллере из одной точке вы должны передавать данные во вью, должен быть один сервис который посмотрит - данные есть - используем, если их нет - передать кому то - получить ответ - используем

но это не отменяет того факта, что в остальных сервисах (а их скорее всего будет несколько) мне всеравно надо будет подключать сервис RateService в переменную $rateService и только потом получать данные. Почему не дергать эти данные сразу?

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

но это не отменяет того факта, что в остальных сервисах (а их скорее всего будет несколько) мне всеравно надо будет подключать сервис RateService в переменную $rateService и только потом получать данные. Почему не дергать эти данные сразу?

а может ты не верно сервис определил? может эти данные не там должны быть? может это вообще должен быть VO ?

VO?

VO?

ValueObject

врядли, скорее он запутался в логике своей

ValueObject

ну вот метод getRate возвращает мне именно VO (если я правильно понял этот паттерн), некую модель, у которой нет никаких дополнительных методов кроме пары связей.

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

просто объект с данными

значит это не VO, если к нему настолько строгие требования

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

вот думаю в месте ДО вызова у вас и есть проблемы

ну вот метод getRate возвращает мне именно VO (если я правильно понял этот паттерн), некую модель, у которой нет никаких дополнительных методов кроме пары связей.

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

ээээ, этот метод вызывается сразу после проверки аутентификации. Поскольку даже на проверку авторизации уже влияют эти данные

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

алилую. То с чего я и начинал. Биндить как примитив или как синглтон? Как это правильно потом использовать?

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

Тогда уж синглтон сервис который знает где и как получить эти данные

ээээ, этот метод вызывается сразу после проверки аутентификации. Поскольку даже на проверку авторизации уже влияют эти данные

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

Тогда уж синглтон сервис который знает где и как получить эти данные

не тут нужен объект, а так получится сервис опять же :)

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

может фабрику в конце концов

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

на ее уровне проверяйте есть ли нужные данные в запросе, и тогда инициализируйте то что вы хотите

далее уже когда до контроллера дойдете, у вас все будет готово

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

а вот это уже замечание в точку. При бинде, есть доступ к сессии или еще нет?

да не надо вам биндить

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

такой сервис есть изначально. Желание именно получить объект напрямую

делайте в сервисе, ленивой инициализации

геттер который посмотрит - уже есть объект и вернет его, если нет то знает как и откуда достать

геттер который посмотрит - уже есть объект и вернет его, если нет то знает как и откуда достать

на данный момент так и есть

да и бинд экземпляра объекта в контейнер... хз удачный ли это вариант

на данный момент так и есть

в общем надо смотреть на твою реализацию, но так как ты описал - биндинг плохая идея

лара поддерживает фабрику для синглтона?

я вот не в курсе, но тут прям ему фабрику надо)

лара поддерживает фабрику для синглтона?

а зачем именно синглтон? можно и обычный содать

при чем с ленивой инициализацией

ну да, похоже на фабрику

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

и уже не проходить процесс инициализации больше

и уже не проходить процесс инициализации больше

потому что там будет не создания объекта, а инстанс лежать

ну тут смотря что ему нужно

ок. С этим я все понял. Другой вопрос

Здраствуйте ребята, допустим у меня есть какой-то текст на странице, который я могу сохранять в БД. Но я хочу сделать его локализованным, чтобы можно было его сохранять для разных языков. Есть какие-то предложения?

тут миллион предложений

контент или статика в верстке?

статика

Здраствуйте ребята, допустим у меня есть какой-то текст на странице, который я могу сохранять в БД. Но я хочу сделать его локализованным, чтобы можно было его сохранять для разных языков. Есть какие-то предложения?

dimsav/laravel-translatable

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

Если у меня сейчас есть модель ClientLocal которая хранится в локальной базе, потом есть желание подключить вместо этой таблицы другую базу с моделью ClientBPM. Я хочу везде использовать просто CLient и соответственно биндить нужную реализацию. Тут я прав надеюсь? =) Так вот вопрос, надо ли создавать абстрактный класс Client или нет?

а в базе использовать например какие то placeholder'ы

зависит от реализации, либо интерфейс либо абстракт точно нужно

ну тоесть пустой файлик точно нужно создавать?

пустой файлик точно создавать не надо

что вы имеете ввиду под пустым файликом?

ну тоесть пустой файлик точно нужно создавать?

бинди интерфейс, а к нему реализацию

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

Так а в транслитератор можно записывать?

что вы имеете ввиду под пустым файликом?

<?php namespace App\Models; class Client { }

идите от интерфейса

пишите сначало интерфейс, потом две его реализации

бинди интерфейс, а к нему реализацию

там нет никаких методов, которые надо реализовывать отдельно

<?php namespace App\Models; class Client { }

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

там нет никаких методов, которые надо реализовывать отдельно

ну а нафиг тебе тогда 2 одинаковых класса?

ну или просто пустой интерфейс

и ты будешь знать, что любой класс который реализует этот интерфейс можно использовать как ClientXXX

ну а нафиг тебе тогда 2 одинаковых класса?

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

скажем так, мне надо знать, что у всех этих моделей есть поле [uid, name ...]. Как это можно прописать в интерфейсе?

или тут тоже не нужен биндинг, а потом просто заменить один класс на другой?