Клиент выбирает услугу, вбивает параметры, вносит бабло этц

ну это глобально, а локально что решаешь?

На данный момент есть репозиторий на мейлбоксе

По факту, мимикрирует под CRUD

Но с последовательной обработкой запросов к базе

ВОт думаю, так его оставить

Или менять

У тебя БД уже готовая?

Ну да

Ну как готовая

Сам пишу, сам читаю

Локальная

Ну ты можешь перехать на ES?

Один пользователь же.

ES - это что?

Эластик?

Event Sourcing.

Ну не совсем понятно, как это мне поможет в моей задаче

Т.е. условно я получаю с сервиса список услуг, мне его надо в некоторых местах иметь

Предлагаешь по записи в базу просто пушить эвенты об обновлении?

И на них подписываться?

Как вариант в целом

Но надо, чтобы это еще в моей ооп картине мира уложилось :)

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

Хммм

А выборки как делать?

Какие выборки? У тебя есть объект (коллекция) полностью представленный внутри актора. Все запросы через актор. Или там какое-то космическое количество элементов в коллекции?

Ну тыщи полторы

Услуги принадлежат одному пользователю?

Или это некий перечень доступных?

Для всех одинаковые

Так что второе

Если внутри будет иммутабельный стейт, то его можно безболезненно выдавать наружу. Я бы сделал запрос GetState, после чего все выборки проводил бы над результатом по месту требования. А от асков избавился бы через: collectionActor <? GetState |> Async.map (List.fold ... >> WrapperMessageType) |!> context.Self

А теперь объясни значки :)

Ты с аккой работаешь?

Угу

<? - ask, пока еще асинхронный. |!> - pipeTo, с ним ты уже сталкивался, run-ит async.

Я бы уточнил что большие объекты не стоит передавать в сообщениях

Почему?

Разве это не тождественно передаче ссылки?

Разве это не тождественно передаче ссылки?

Нет

petabridge.com

Тут много постов полезных

petabridge.com

Один из них как раз говорит о больших сообщениях см. http://petabridge.com/blog

Кластеры?

Мы вроде только про локальную машину говорили.

Не только про кластеры)

Машина локальная

Не только про кластеры)

Тыкни в статью, плиз.

Тыкни в статью, плиз.

10 минут.

Разве это не тождественно передаче ссылки?

По умолчанию инпроцесс мессаги НЕ сериализируются (для скорости). Если мессаги идут через нетворк, то они точно сериализируются. Можно включить сериализацию ин процесс и получить падение скорости на два порядка, зачем это делать, чтобы гарантировать иммутабельность сообщений (это если кодеры совсем криворукие). Резюме. Если ты инпроцесс делаешь и у тебя конфиг дефолтный, то месаджи по ссылке передаются, иммутабельность на программисте

Так и думал. Так что в нашем случае все гуд.

@Kleidemos Поясни за context.Self

Ayrat А ты можешь дать инструктаж, как делать массовые опросы акторов? Ощущаю, что я велосипедю по страшному.

@Kleidemos Поясни за context.Self

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

Ayrat А ты можешь дать инструктаж, как делать массовые опросы акторов? Ощущаю, что я велосипедю по страшному.

Есть два пути. Сделать актора, который будет знать о состоянии акторов априори (держать словарь своих детей например с времени последнего ответа от них) или реально делать броадкасты. Второй случай ну такой себе, я предпочитал диспетчера, который знает о всех

Такс, еще один сценгарий

Выбираем услугу, надо показать дочерние

По умолчанию инпроцесс мессаги НЕ сериализируются (для скорости). Если мессаги идут через нетворк, то они точно сериализируются. Можно включить сериализацию ин процесс и получить падение скорости на два порядка, зачем это делать, чтобы гарантировать иммутабельность сообщений (это если кодеры совсем криворукие). Резюме. Если ты инпроцесс делаешь и у тебя конфиг дефолтный, то месаджи по ссылке передаются, иммутабельность на программисте

Окч спасибо за разъяснения.

А статью я поищу.)

Отдельный childActor?

Отдельный childActor?

Ты можешь все дерево представить в рамках одного актора?

Предположим ты хочешь CRUD. Делаешь актора диспетчера который отвечает за работу с БД, там делаешь разворачивание твоих доменных запросов/команд в SQL например. Он знает о N акторах, которые умеют отправлять SQL команды в БД (лоу левел акторы, которых может быть много) Все кто хотят так или иначе получить что-то от БД, шлют запрос диспетчеру работы с БД и меняют свой стейт на "Ожидаю получения инфы, отвалите от меня", чтобы оставаться реактивными. Когда им в мейлбокс прилетает ответ, они реагируют на него, что-то делают и переходят в другое состояние

Короче, дело ясное, что пока тёмное

Есть два пути. Сделать актора, который будет знать о состоянии акторов априори (держать словарь своих детей например с времени последнего ответа от них) или реально делать броадкасты. Второй случай ну такой себе, я предпочитал диспетчера, который знает о всех

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

У меня есть пример, но он не хелоуворлд)

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

Есть роутеры. Не совсем то. Но может помочь

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

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

Есть примитив броадкаста, но без ответов. Т.е. положить всем акторам в мейлбоксы этот месадж - такой примитив есть.

И да, это актор роутер просто

Можно считерить и через ActorSelection отправить

типа отправь всем по пути /user/sql-actors/*

Есть примитив броадкаста, но без ответов. Т.е. положить всем акторам в мейлбоксы этот месадж - такой примитив есть.

Куда смотреть?

https://getakka.net/articles/actors/routers.html

ctrl-f Broadcast

Тыкни в статью, плиз.

https://petabridge.com/blog/large-messages-and-sockets-in-akkadotnet/

https://petabridge.com/blog/large-messages-and-sockets-in-akkadotnet/

тут про Ремоут если чо, т.е. нетворк

у него всё инпроцесс

И да, это актор роутер просто

Стоит сказать, что роутеры быстрее обычных акторов.

тут про Ремоут если чо, т.е. нетворк

Да-да. Я все же обещал статью)

https://getakka.net/articles/actors/routers.html

Эт по моему не про мой случай. Хотя я еще поковыряю.

Эт по моему не про мой случай. Хотя я еще поковыряю.

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

Что значит "тяжкой"?

Ну, там больше 2х классов

Эт C#?

Ага

Ужас.

Но эту репку потом портировали на F# достаточно просто, потому что она фукциональненько написана

Там короче попытка писать как на F# только на C#

Давай. // Я так понимаю, что к портированному варианту меня пускать нельзя.

Правильно понимаешь)

почту скинь, репка на VSTS

можешь в личку

Есть ли в Rider возможность прикрутить некое подобие #region для F#?

Чтобы коллапсить куски кода

В акке можно намутить кастомный стрим наподобие system.EventStream, чтобы на него акторы подписывать?

а чем EventStream не устраивает?

Ну помойка же

Из разных типов сообщений