C# - Забавная штука со штатным JSON сериализатором
Берём составной тип, но в принципе ничего сложного. Только есть свойство-коллекция с типом-интерфейсом - скажем, IEnumerable<int>. Далее сериализуем в джейсон, затем десериализуем, и снова сериализуем, но уже в XML - получаем ошибку
ошибка: System.Text.Json.JsonElement was not expected. Use XmlInclude or SoapInclude attribute to specify types that are not known statically.
Откуда этот JsonElement взялся? Десериализатор там что-то своё добавляет?
Кто не понял:
object - JsonSerializer.Serialize - JSON string - JsonSerializer.Deserialize - object - XmlSerializer.Serialize - ошибка
Похоже, ошибка именно в десериализации через встроенный в Дотнет JsonSerializer, т.к. если эту же джейсонку скормить сериализатору от NewtonSoft, то он такой херни не делает. Т.е. после его десериализации, дотнетовский XML-сериалайзер нормально сериализует объект.
object - JsonSerializer.Serialize - JSON string - (NewtonSoft)
JsonConvert.DeserializeObject - object - XmlSerializer.Serialize - успех
object - JsonConvert.SerializeObject - JSON string - JsonConvert.DeserializeObject - object - XmlSerializer.Serialize - успех
PS. Кстати, у МС у самой неконсистентность в названиях - пространства имён Xml и IO. В одном случае оббревиатура через маленькие буквы, в другом - через большие.
Чёт херня какая-то. Щас попробовал - со штатным получилось. Коллекция правда пустая (XML-сериализатор штатный интерфейсы не сериализует), но уже без ошибки.
Я там правда код немного поменял, но уже не верну старую версию.
Ладно, значит я ступил чего-то, недосмотрел.
ПС. А имена пространств имён всё равно неконсистентны.
Я своим заказчикам тоже сказал - желательно брать JSON-сериалайзер, Radzen и Entity Framework - получите из коробки быстрый и удобный UI, запросы к БД и сериализацию этих запросов. Нет, сказали юзать XML, свою старую ORM-клячу и корявые кастомные модели для UI-компонентов. Такое ощущение, что народ не хочет быстро и качественно, а хочет до пенсии поддерживать свои костыли.
Есть таблица с настраиваемыми фильтрами - типа визуальный конструктор запросов. Для обычных пользователей, не программистов. Надо эту визуальщину преобразовывать в запрос к БД, а также сохранять в БД сам запрос и восстанавливать настройки этого запроса в визуальном конструкторе. Т.е. у конструктора есть некий объект, хранящий все фильтры - вот этот объект и надо превращать в SQL и сериализовать в строку для хранения в БД. По идее, можно SQL обратно распарсить в такой объект, но они решили для хранения в БД использовать XML. Поэтому этот объект настроек фильтров должен и в SQL, и в XML (и обратно) конвертироваться.
Штука ещё в том, что UI может поменяться, а сохранённые настройки в БД останутся от старого. Поэтому нужен промежуточный объект, который не будет меняться в зависимости от UI. Что-то типа такого
UI filter settings - DTO object - DB query
Если бы они юзали стандартный EF, то проблемы бы не было - в каждой уважающей себя UI-либе есть его поддержка из коробки, ничего писать не надо - т.е. промежуточный узел с DTO не нужен, все конвертации из UI в запросы проходят автоматически, сами запросы сериализуются в JSON их можно сохранять и снова загружать в UI, восстанавливая все настройки фильтров. Но у них своя ORM на датасетах, при этом хреново сериализуемая (например, у кучи типов нет сеттеров, нужных для сериализации в XML, плюс кода какие-то немереные килотонны - задолбаешься обвешивать атрибутами сериализации и потом полученный гигансткий объект сохранять в БД). Там либо переписывать всё, либо писать DTO. А они ещё усугубляют, заставляя юзать XML, а не JSON (который тоже любой нормальной либой из коробки поддерживается). Я выбрал DTO с минимальными настройками длс запроса - без лишнего мусора их самописной ORM. В результате я должен писать конвертеры ORM - DTO и UI - DTO, а сам DTO делать сериализуемым в XML, чтобы его потом в БД сохранить.
Radzen
Не всё там пока получается. Tooltip не запустился, пытаются подгрузить либу с другим именем.
WaitCursor там тоже не нашел
что народ не хочет быстро и качественно
народ не хочет ничего менять. Будет ли новое лучше никто не знает.
А когда допустим, сделаешь, скажут а вот так еще не работает. Так не говорили же, что так должно работать - а у нас всегда так работало надо было знать...
Ну теперь хоть немного понятно отчего народ не хочет нового?
Да, возможно, через какое то время оно оправдается / а может и нет/
А тут уже всё протестено за х лет вдоль и поперек. Работает на ура. Нужно только это новое поле и пара кнопочек.
Смотреть нужно не со стороны разработчика.
Всё может быть, но своя костыльная ORM всяко должна быть заменена на хотя бы EF. Это не должно обсуждаться. Нет - будем развивать и доводить до ума нашу старую самописную ORM 15-летнего возраста. У старой самописной ORM сериализация не поддерживается - мути-колдуй, расставляй атрибуты по куче классов, обвешивай костылями. У EF же всё сериализуется со свистом из коробки (благодаря в том числе Dynamic LINQ).
своя костыльная ORM всяко должна быть заменена на хотя бы EF
-----
Перед тем как изрекать глупости стоит ознакомится с возможностями технологии.
В данном случае тебе предлагается сделать простой тестик - написать что-то маленькое с использованием EF.
С чем тебе надо будет заставить его работать тебе будет сообщено после релиза.
Это не должно обсуждаться
Всё должно обсуждаться. Хотя бы простой вопрос - сколько нужно тебе времени на замену и отладку старой ORM?
И как будет гарантировано, что новая система будет работать точно также как старая? И не забывай, что могут быть проекты использующие старую ОРМ о которых лично ты никогда не слышал.
