LL
"лучше" в данном случае было бы повесить алиас на результат вызова compile_env, но это так не работает
А что мешает использовать аттрибут?
Size: a a a
2020 October 23
AB
мне его в каждом модуле вешать, чтоли?
AB
ок, может быть его можно вывесить из using, как и алиас.
AB
но атрибуты это все равно, кхм, неизящно и не факт, что масштабируется
LL
но атрибуты это все равно, кхм, неизящно и не факт, что масштабируется
А как это должно масштабироваться? И какую задачу ты вообще решаешь?
AB
А как это должно масштабироваться? И какую задачу ты вообще решаешь?
DI по сути. предоставление провайдеров чего-либо в отчуждаемое приложение.
AB
вот кстати, как бы вы делали реюзабельный контекст, работающий с внешними системами?
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
@LamaLove вот это вчерашнее
LL
DI по сути. предоставление провайдеров чего-либо в отчуждаемое приложение.
dependency injection обычно делают через аттрибуты
AB
dependency injection обычно делают через аттрибуты
атрибуты не эквивалентны алиасам, например. они выглядят по-другому.
LL
@LamaLove вот это вчерашнее
А вот для зависимости, которая использует репо проекта, который её использует, я бы сначала ответил на два вопроса
1) Зачем использовать
2) А почему бы не предоставлять свой
1) Зачем использовать
Repo? Типа Repo это же просто набор функций, исполняющих запросы. Разве не достаточно предоставить только запросы?2) А почему бы не предоставлять свой
Repo, чтобы проект-хост использовал его? Я с таким подходом прямо сейчас работаю и в нём ничего страшного нет ...LL
Я вообще не люблю всякие нечистые зависимости, которые за моей спиной лезут в базу и всё вот это вот
AB
2 - точно нет. зачем мне две конфигурации Repo, если можно обойтись хостовой?
AB
опять же, если репо два, нужно задумываться, что у тебя висит х2 коннектов.
сейчас мне пофиг, у меня pgbouncer, но завтра его может не быть. или он есть в проде, но нет на тестовом окружении.
сейчас мне пофиг, у меня pgbouncer, но завтра его может не быть. или он есть в проде, но нет на тестовом окружении.
AB
А вот для зависимости, которая использует репо проекта, который её использует, я бы сначала ответил на два вопроса
1) Зачем использовать
2) А почему бы не предоставлять свой
1) Зачем использовать
Repo? Типа Repo это же просто набор функций, исполняющих запросы. Разве не достаточно предоставить только запросы?2) А почему бы не предоставлять свой
Repo, чтобы проект-хост использовал его? Я с таким подходом прямо сейчас работаю и в нём ничего страшного нет ...1 - вот это зависит. да, можно наружу отдать Multi, но в такой ситуации нет возможности оттранслировать ошибки.
AB
с defdelegate другая проблема - optional_callbacks. должны ли они делегироваться?..
по-хорошему - только тогда, когда они есть в таргет-модуле, но таргет-модуль в хосте, и в общем случае на момент компиляции зависимости не скомпилирован.
по-хорошему - только тогда, когда они есть в таргет-модуле, но таргет-модуль в хосте, и в общем случае на момент компиляции зависимости не скомпилирован.
AB
оч плохо.
AB
да, похоже, алиас из using работает лучше всего.
AB
правда, это всё работает только для стейтлесс-зависимостей или зависимостей, где весь стейт известен в компайл-тайме.
AB
правда, это всё работает только для стейтлесс-зависимостей или зависимостей, где весь стейт известен в компайл-тайме.
наверное, можно даже сказать "работает только для синглтонов"
LL
2 - точно нет. зачем мне две конфигурации Repo, если можно обойтись хостовой?
Я о другом
Зачем использовать хостовую, когда хост может использовать репо из зависимости
Зачем использовать хостовую, когда хост может использовать репо из зависимости