Shub
в том смысле, что ок, допустим не класс, допустим я сделаю рекорд с полем type
Shub
но все равно: матчить по DU или по полю рекорда (которое тоже DU) - разница небольшая
Vasily
Информацию о du все равно надо где-то хранить
Anonymous
но все равно: матчить по DU или по полю рекорда (которое тоже DU) - разница небольшая
Так если я правильно понял, то у тебя и вариантов даже в теории нет. В джойсоне нет никакой метаинформации о принадлежности тому или иному кейсу суммы. Значит, ты не можешь решить проблему без перебора доступных вариантов.
Anonymous
Ну или я вообще не понял проьлему.
Shub
Все равно придется в каком-то месте писать какому сообщение какой тип соответствует. И это будет не малкнький список.
в нормальном языке есть clauses - erlang\haskell, в мейнстриме есть перегрузка методов. компилятор за меня решит, какой метод вызвать, глядя на тип параметра. в эфшарпе че-то ничего в голову не приходит
Vasily
Вопрос, как ты будешь информацию о пейлоде хранить
Vasily
Ну т.е. приезжает условный жсон
Shub
ты все также полагаешься на добрую волю разрабов, ибо от слова "пэйлоад" ты никуда не ушел
компилятор не даст собрать проект с экземпляром класса, в котором нет payload. компилятор соблюдет статическую типизацию
Vasily
Который надо десериализовать в определенный тип
Vasily
Откуда информация о типе будет взята?
Anonymous
компилятор не даст собрать проект с экземпляром класса, в котором нет payload. компилятор соблюдет статическую типизацию
А если завтра у вас еще другой ЯП появится вне дотнета? Или этот вариант не рассматривается и вся система будет знать только про твой АйМэсседж?
Shub
А если завтра у вас еще другой ЯП появится вне дотнета? Или этот вариант не рассматривается и вся система будет знать только про твой АйМэсседж?
вся система уже сейчас не знает про мой эфшарп, система знает только про гарантированный контракт выраженный жсоном
Shub
что там внутри моего кода систему, мягко говоря, не волнует
Shub
варианты "завтра у вас появится другой ЯП" я оцениваю приблизительно с той же вероятностью, как и миграцию на AWS
AlexxSt
вся система уже сейчас не знает про мой эфшарп, система знает только про гарантированный контракт выраженный жсоном
А может тебе тупо написать генератор разбора, если спеки готовые есть?
Shub
если бы этот жсон присылался мне от своих же - то это было бы полбеды, можно было бы банально слать f# представления жсонами, по крайней мере вопрос с быдлопарсингом снялся бы
Shub
А может тебе тупо написать генератор разбора, если спеки готовые есть?
это 100% придется сделать. я пытаюсь обернуть свою голову вокруг самого эргономичного способа это сделать. тут еще есть ньюанс, что мне настоятельно рекомендовано использовать только определенные либы
Shub
как план Б я все же рассматриваю TypeShape\UnionEncoder
Shub
но еще больше хочется придумать обобщенный метод работы с этими ивентами, не описывая обработку каждого кейса вручную и не диспетчеризуя обработчики вручную
Shub
пусть работает железный паровоз, как говорится
Anonymous
Требования суровые?
Shub
шоб вам было понятно, в чем проблема - вот пример реального жсона
Shub
https://pastebin.com/cScLnEBJ
Anonymous
Линкедлист обработчиков до первого победителя сойдет?
Anonymous
Диспетчеризацию за тебя условный цикл фор и случай сделают
Shub
а, еще я забыл рассказать про нарушения контрактов, лол. например, поля, которые выглядят как enum - могут принимать пустые значения или вовсе null. в зависимости от значений других полей
Shub
dид советует писать все вручную. ну типа в деревнях вообще все вручную и ничего. ко мне уже стоит очередь свидетелей дида с книгой мормона в руках, но это такое, отобьемся, лол
Shub
Линкедлист обработчиков до первого победителя сойдет?
оно там щас так и сделано, посмотри по первой ссылке
Vasily
У тебя конечное число примитивных типов
Shub
только там возможностей ошибиться сильно дофига
Vasily
Соответственно, нужно промежуточное представление
Vasily
Я с таким баловался
Shub
у нас подавляющее большинство случаев - это DU, в каждой ветке которого одна структура
аля
type EventData = {}
type MyEvent = Created of EventData | Updated of EventData | Deleted of EventData
Shub
тут как бы сильно дохера шансов
Vasily
Одна и та же структура?
Anonymous
оно там щас так и сделано, посмотри по первой ссылке
это выглядит как неплохое решение с учетом нежелания ничего делать руками. единственное, что у тебя дофига типизации, а хендлеры могли бы получать тех же dynamic'ов, если лень типизировать и сваливаться при первой же неудаче в None например. цикл до первого Some result или логгирование того, что такой-то запрос не был обработан, т.к. не нашлось хендлера.
Anonymous
если нет требований к перфомансу, то так будет проще всего
Roman
у нас к сожалению выбор ограничен только ньютонсофтом. но допустим я могу запилить обобщенную сериализацию. вопрос, как дальше быть с DU? сама идея выносить поле type на уровень выше как-то не очень
По поводу ограниченности выбора — ты можешь из фшарп лу взять конвертер, а саму сериализацию так и ебошить через ньютонсофт.
Vasily
Я бы все же структуру данных поменял
Vasily
Ошибка в том , что десериализация должна быть не в рекорд
Vasily
Список ключ значение
Vasily
Чем жсон и является
Shub
это выглядит как неплохое решение с учетом нежелания ничего делать руками. единственное, что у тебя дофига типизации, а хендлеры могли бы получать тех же dynamic'ов, если лень типизировать и сваливаться при первой же неудаче в None например. цикл до первого Some result или логгирование того, что такой-то запрос не был обработан, т.к. не нашлось хендлера.
50 строк кода с нулевой логикой для тривиального случая "жсон с 5 полями" - это "выглядит нормально"? я боюсь представить себе "ненормально", даже с опытом текущего проекта. если что, в жаве это всего лишь определение класса с нужными полями и несколько аннотаций. статических гарантий не меньше (а то и больше), чем в эфшарпе
Vasily
Соответственно сериализация и десериализация пишется руками один раз
Shub
Список ключ значение
и как это парсить потом? наличие ключа в жсоне в общем случае не гарантируется
Hog
Соответственно сериализация и десериализация пишется руками один раз
потом из этого всё равно "бизнесс-рекорд" надо делать
Shub
потом из этого всё равно "бизнесс-рекорд" надо делать
рекорд - это ок. вопросы к представлению в виде DU
Vasily
Бизнес рекорд в конструктор принимает такой список
Shub
может значения?
и того, и другого. жсон шлют разны системы, одни могут прислать key: null, другие могут key не прислать
значение null может быть допустимым при определенных значениях других полей
Vasily
Shub
Бизнес рекорд в конструктор принимает такой список
у рекорда нет конструктора, или это о другом?
Hog
тогда только как Василий предложил
Shub
псевдокод бы не помешал, т.к. пока что это звучит "давай ты переименуешь этот метод в конструктор бизнесс-рекорда"
Vasily
Я про то, чтобы ввести слой промежуточного предоставления
Vasily
У тебя это что угодно будет нарушать
Roman
нарушает invalid type non representability
тебе нужны отдельные типы для валидной доменной модели
Shub
тебе нужны отдельные типы для валидной доменной модели
решить проблему "много кода" добавлением кода? ок
Roman
Не надо пытаться распарсить произвольный жсон сразу во вменяемое нечто с доменной точки зрения
Shub
вы че-то сконцентрировались на парсинге
Shub
валидация в моем случае крайне простая - я имею право просто игнорировать такие жсоны
Roman
бля, речь не про то, что ты сделаешь с невалидным жсоном, а про то, как отличить валидный от невалидного и как собрать из валидного жсона вменяемый тип
Shub
бля, речь не про то, что ты сделаешь с невалидным жсоном, а про то, как отличить валидный от невалидного и как собрать из валидного жсона вменяемый тип
угу. про вменяемый тип как раз и речь
Shub
поинт в том, что DU - это невменяемый тип
Roman
хз, надо понимать доменную модель, чтобы сделать этот вывод или опровергнуть его
Shub
доменной модели как таковой нет, пайплайн, который слушает входящие от нескольких разных (но сходных) систем и складывает это в БД. вся логика - в экономии запросов в БД, ну типа комбинирование нескольких апдейтов в один
Shub
но блин из-за этого представления этих сообщений в виде du код раздувается как на дрожжах
Shub
и я задолбался ловить тупые ошибки за своими коллегами
Vasily
но блин из-за этого представления этих сообщений в виде du код раздувается как на дрожжах
Я предлагаю заменить du