Никто так и не объяснил почему

сервис локатор это зло

Не спорю

Но чем лучше собирать все руками вместо тупой регистрации мне не понятно

Кроме мнимой типобезопасности

Не такой уж и мнимой. Уж сколько раз ломал и чинил приложения по причине: незареген сервис

Никто так и не объяснил почему

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

Но чем лучше собирать все руками вместо тупой регистрации мне не понятно

тем, что тут заранее явно и очевидно, что и где надо зарегать. И ничего в рантайме не отъебнет

Хз, переизобретение колёса и не более

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

Хз, переизобретение колёса и не более

ок как скажешь

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

Аргумент про динамичность работает так же и для DI с пресловутым constructor injection. Про неявность - согласен

ок как скажешь

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

Аргумент про динамичность работает так же и для DI с пресловутым constructor injection. Про неявность - согласен

Constructor injection можно проверить на стадии компиляции

Аргумент про динамичность работает так же и для DI с пресловутым constructor injection. Про неявность - согласен

да, конструктор инжекшн так же динамичен, но уже хотя бы очевиден список зависимостий

Посмотрим когда зависимостей много

Что будет

Constructor injection можно проверить на стадии компиляции

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

Constructor injection можно проверить на стадии компиляции

А как?

Посмотрим когда зависимостей много

bounded context.

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

Если с конструкторами? Довольно просто. Мне известны всё типы, которые мы резолвим, следовательно, можно их все попробовать зарезолвить

зарезолвить на стадии компиляции?

Да, я не вижу проблему это сделать во время сборки проекта

пост билд ивентом чтоль?

Да какая разница как? Мы реализацию что ли пишем? Например, пост билд эвентом, но возможно другим. Там много стадий, я на память не помню

ну это уже не стадия компиляции

Да даже на стадии компиляции можно

Это автомтизировано, так что это лучше, чем ничего

Метод резолв - он обычно один

ну это уже не стадия компиляции

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

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

А как бы нам тогда в модуль регистрации зависимостей прокинуть конфиги?

Вон, в 3.0 завезли вроде проверку

Короче

С этими DI, конечно, играться можно

А как бы нам тогда в модуль регистрации зависимостей прокинуть конфиги?

Его единственным что ли мокать придётся? А потом поддерживать это как-то

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

Ща мне, канеш, начнут говорить, что надо правильно проектировать

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

Но, к сожалению, правильное проектирование с первой итерации - оксюморон

ahaha waterfall go wooooshhh

Но у меня область специфическая - надо быстро и чтобы работало

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

у меня весь AppEnv с чтениями из конфига и object expressions занимает 130 строк очень простого кода.

Особо времени на архитектурные изыски нет

у меня весь AppEnv с чтениями из конфига и object expressions занимает 130 строк очень простого кода.

Ты же этот AppEnv во все функции прокидываешь, получается

интерфейсы к нему еще 20 строк

Ты же этот AppEnv во все функции прокидываешь, получается

в 4-5 функций в сумме

остальные чистые

Ну не знаю

Короче, вопрос холиварный

ну как хотите

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

почему все?

С какого сообщения читать про тайпклассы vs DI?

Я всего лишь пытаюсь упростить себе жизнь. Мне проще 1 раз подумать подольше и написать предельно говорящий и явный код, чем побыстрее что-нить пушнуть в мастер сейчас, но потом ковыряться в логах в поисках ответа на вопрос "как возникла такая хуйня" и "почему тут отъебнуло"

С какого сообщения читать про тайпклассы vs DI?

не было про тайп классы покашто, но давай, набрасывай

не было про тайп классы покашто, но давай, набрасывай

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

ну в фшарпе сегодня тайпклассов нет, так что сорян. Со скалой/хаскелем у меня опыта нет, поэтому я и тайпкласс-то в руках не держал

Просто аргумент "чтобы все можно было протестировать" - он такой себе

Благими намерениями, как известно

Сам знаешь куда дорога вымощена

это все слишком абстрактные философствования. Было бы применимо, если б я замутил лютый овер инжиниринг во имя чего-то маловероятного. А так у меня код прост как 5 копеек, и его вряд ли даже больше, чем ушло бы на регистрацию компонентов

т.е. я пока не услышал даже конкретных недостатков подхода кроме "ну такое себе" и "по-мойму колесо"

Я всегда задаюсь вопросом, насколько такая формализация усложняет разработку

Ну т.е. сколько там бойлерплейта, в котором надо разобраться, как оно работает

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

Ну т.е. сколько там бойлерплейта, в котором надо разобраться, как оно работает

type ICatalogDb = abstract member GetProductItem: string -> Async<ProductItem option> abstract member GetItems: string seq -> Async<ProductItem[]> abstract member GetPrices: string seq -> Async<ProductItemPrice[]> abstract member GetInventories: string seq -> Async<Inventory[]> type IProductBlob = abstract member SaveProduct: ProductId -> Localized<LocalizedCompleteProduct> -> Async<Result<unit, exn>> type IAppEnv = abstract member CatalogDb: ICatalogDb abstract member ProductBlob: IProductBlob abstract member Logger: ILogger abstract member Config: CatalogConfig abstract member ActorSystem: ActorSystem abstract member UpdateRouter: IActorRef<UpdateRouterMessage> abstract member UtcNow: DateTimeOffset

Ну вот уже как-то дохера

Хотя, возможно, я просто ничего в этом не понимаю

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

Отличная штуковина!

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

Ну вот уже как-то дохера

Лол. Нуштош, не буду больше настаивать

type ICatalogDb = abstract member GetProductItem: string -> Async<ProductItem option> abstract member GetItems: string seq -> Async<ProductItem[]> abstract member GetPrices: string seq -> Async<ProductItemPrice[]> abstract member GetInventories: string seq -> Async<Inventory[]> type IProductBlob = abstract member SaveProduct: ProductId -> Localized<LocalizedCompleteProduct> -> Async<Result<unit, exn>> type IAppEnv = abstract member CatalogDb: ICatalogDb abstract member ProductBlob: IProductBlob abstract member Logger: ILogger abstract member Config: CatalogConfig abstract member ActorSystem: ActorSystem abstract member UpdateRouter: IActorRef<UpdateRouterMessage> abstract member UtcNow: DateTimeOffset

Выглядит разумно

type ICatalogDb = abstract member GetProductItem: string -> Async<ProductItem option> abstract member GetItems: string seq -> Async<ProductItem[]> abstract member GetPrices: string seq -> Async<ProductItemPrice[]> abstract member GetInventories: string seq -> Async<Inventory[]> type IProductBlob = abstract member SaveProduct: ProductId -> Localized<LocalizedCompleteProduct> -> Async<Result<unit, exn>> type IAppEnv = abstract member CatalogDb: ICatalogDb abstract member ProductBlob: IProductBlob abstract member Logger: ILogger abstract member Config: CatalogConfig abstract member ActorSystem: ActorSystem abstract member UpdateRouter: IActorRef<UpdateRouterMessage> abstract member UtcNow: DateTimeOffset

Потом все зависимости создаёте object expression'ами, в composition root передаёте appEnv, а дальше в нижележащие функции уже конкретные, например, appEnv.CatalogDb ? если не нужен весь appenv

Потом все зависимости создаёте object expression'ами, в composition root передаёте appEnv, а дальше в нижележащие функции уже конкретные, например, appEnv.CatalogDb ? если не нужен весь appenv

да, как-то так

Здрасьте

Привет

Потом все зависимости создаёте object expression'ами, в composition root передаёте appEnv, а дальше в нижележащие функции уже конкретные, например, appEnv.CatalogDb ? если не нужен весь appenv

let catalogDb = { new ICatalogDb with member _.GetProductItem itemId = getFromCosmos productItemToDomain itemId member _.GetItems ids = async { let! docs = CosmosCatalogDb.getItems cosmosClient ids return docs |> Array.map productItemToDomain } member _.GetInventories ids = async { let! entities = CosmosCatalogDb.getInventories cosmosClient ids return entities |> Array.map inventoryToDomain } member _.GetPrices ids = async { let! docs = CosmosCatalogDb.getPrices cosmosClient ids return docs |> Array.map priceToDomain } }

Однако. бойлерплейт подъехал

Тут ведь из бойлерплейта по сути только создания объекта. Функции-мемберы в любом случае где-то будут реализованы. Либо сгруппированы в одну зависимость как здесь, либо где-то в модуле, либо где-то ещё

Да Василий как всегда