Vasily
Логика переключения экранов этц - на акторах целиком
Vasily
А это чисто вм от акторов отвязать
gsomix
Vasily
Мысли есть, как упростить?
Vasily
Выглядит действительно запутанно
Pavel
А может все-таки не надо отвязывать vm от актора? Ну или сделать как-то проще, передать в конструктор интерфейс какой-нибудь обвертки над актором?
Pavel
концепция с IContextSource выглядит как-то запутано для меня
Vasily
В конструктор по идее можно передавать только интерфейс для апдейта контекста
Vasily
Тут проблема с получением контекста в основном
Pavel
я не совсем понимаю что есть контекст. Какой-то снэпшот состояния актора?
Vasily
Снэпшот состояния сессии ui
Éminence grise
Вась, а ты бы объяснил, зачем тебе акторы здесь. А то из кода не ясно.
Vasily
Ui тут скорее как одно из представлений системы акторов
Vasily
Планирую ещё веб развернуть
Éminence grise
Тогда я вообще ничего не понял. На кой актору знать о контексте вью?
Vasily
Ну стейт сессии хранится в акторе
Éminence grise
Нда, мистер знаток тонких извращений (восхищенно). Пусть стейт будет родительским актором к этому
Vasily
Нда, мистер знаток тонких извращений (восхищенно). Пусть стейт будет родительским актором к этому
Не хочу вязать экран жестко
Éminence grise
Чем у тебя управляет актор?
Vasily
Ну это будет банковский терминал
Vasily
Потом как сервер разверну
Éminence grise
То есть актор принимает команды управления счетом?
Vasily
Для веб платежей
Éminence grise
Но самого счета не знает.
Vasily
Платежи
Vasily
Счетов не знает, естественно
Vasily
Это ж не процессинг
Vasily
А нашлепка сверху
Éminence grise
То есть вводишь назначение оплаты -> потом сумму -> деньги -> опрос сети -> результат?
Vasily
Ну скорее отправка того, что я хочу оплатить,на удаленный сервер
Éminence grise
Это не актор а стейт машина. Причем сугубо однопоточная. По моему оверинжениринг. Хотя на акторах можно сделать стейть машину, но на кой?
Vasily
Ну акку- то хочется освоить
Éminence grise
Ну так ты ее не освоишь. Нельзя же для изучения WPF веб приложения писать 😊
Vasily
Плюс актор система позволяет ввести понятие виртуального терминала, что позволит не допиливать удаленный сервер
Pavel
Это не актор а стейт машина. Причем сугубо однопоточная. По моему оверинжениринг. Хотя на акторах можно сделать стейть машину, но на кой?
как на кой? Чтобы не было так скучно и однообразно
Vasily
В сценарии с платежами через веб
Vasily
Вот через веб как раз система многопоточная
Vasily
Точнее, многосессионная будет
Éminence grise
Акторная модель - про конкурентность и многопоточность. Но никак не про стейты. И никак не запихивается.
Vasily
Короче
Vasily
С помощью актор модели удобно представить модель терминала
Vasily
С его устройствами
Vasily
Типа купюроприемника и прочего
Éminence grise
Вот с вебом у тебя сессии нет. Забудь. Если хочешь держать нагрузку - только id актора сессии. Вот здесь получится. И неплохо.
Vasily
Плюс реюзабельность кода
Vasily
Ну как бы и есть id актора сессии
Éminence grise
Не, ни фига у меня твои идеи не укладываются. И никакого реюзабилити не вижу пока.
Vasily
Ок, попробую объяснить
Pavel
Акторная модель - про конкурентность и многопоточность. Но никак не про стейты. И никак не запихивается.
Чем акторная модель отличается от традионного ООП?
Vasily
С помощью актор модели удобно описывать изменяющуюся систему
Éminence grise
Формально - есть сервис - есть терминал. Терминал говорит мастер актору - я открываю новую сессию - дальше получает реф на сессион актор, у него все просит. События от аппаратуры ты будешь получать все равно последовательно.
Vasily
Иван, проблема в том, что сервис, который на той стороне, в целом умеет работать только с терминалами
Vasily
Поэтому там свои приколы
Vasily
И лезть я в него не буду, там додревняя Java
Éminence grise
ТОгда все, я спекся. Понять ничего нельзя. Но вот то что ты сделал, как то сурово через ...
Vasily
Я лучше напишу модель терминала на основе акторов
Vasily
Заодно освою новую технологию :)
Éminence grise
Ты лучше задачу сформулируй. Тогда и посмотрим. Полностью.
Vasily
Ты хочешь, чтобы я тебе доменную область целиком описал?
Ayrat
Акторная модель - про конкурентность и многопоточность. Но никак не про стейты. И никак не запихивается.
Любой стейт записывается в актора. Я бы сказал что актор модель это про управление стейтами в конкурентной среде. Стейты там очень даже при чем. Во главе угла, т.к. у каждого актора есть поведение
Éminence grise
Ну не целиком, это долго. Но в общих чертах. А не как то непонятно.
Vasily
Есть терминал, у него куча устройств
Vasily
ПОдходит юзер, тыкает в экран
Vasily
Заполняет параметры
Vasily
Сует бабло
Vasily
Все это уходит на сервер
Éminence grise
Любой стейт записывается в актора. Я бы сказал что актор модель это про управление стейтами в конкурентной среде. Стейты там очень даже при чем. Во главе угла, т.к. у каждого актора есть поведение
Ты не прав хотя бы потому, что стейтлесс акторы никто не отменял. Акторы - это строго по конкуретные очереди с однопоточной синхронизацией и восстановлением после сбоя.
Vasily
Однако у акторов есть поведение
Pavel
Любой стейт записывается в актора. Я бы сказал что актор модель это про управление стейтами в конкурентной среде. Стейты там очень даже при чем. Во главе угла, т.к. у каждого актора есть поведение
в такой формулировке идеально ложится на UI-приложения, т.к. управление состоянием в конкурентной среде - главная проблема юайчика.
Vasily
КОторое можно менять
Ayrat
Ты не прав хотя бы потому, что стейтлесс акторы никто не отменял. Акторы - это строго по конкуретные очереди с однопоточной синхронизацией и восстановлением после сбоя.
Ну нет. Актор модель - теория известная далеко до ерланга и акки
Vasily
Чет Иван прям подвозбудился
Vasily
Актор модель позволяет достаточно просто описывать сложные взаимодействия
Éminence grise
Ну есть немного. Время просто надо убить 😊
Vasily
В моем случае (я тупой, да) это большой плюс
Vasily
Когда надо писать не условную систему дифуров, а просто переходы состояний
Vasily
Это старый спор, как правильно моделировать систему
Vasily
Исконно русский - написать систему дифуров