C# - быстро склонировать несложный объект
Я точно не знаю, как эта ситуация обрабатывается. Ссылочные данные могут быть сериализованы ссылками в той либе. Но ссылке в джейсоне не стандартизированы, поэтому каждая либа их делает по-своему.
А циклы - можно не сериализовать. Но непонятно, что это значит - вообще поле пропускается, или на глубину 1 всё же сериализуется. Тестировать надо. По идее, если ссылочные типы просто заменять ссылками, то циклов возникать не должно - мы просто пишем для ссылочного поля его ссылочный айди (в нотации сериализованного джейсона - см. выше мой линк на ту либу), и дальше вглубь это поле не сериализуем. Всё, от цикла избавились.
Но опять же, логика присвоения эти ссылочных айди - чтобы на одну ссылку разные айди не присвоил. Есть ли там сравнение адресов ссылок, или просто каждому следующему ссылочному полю идёт присвоение инкрементированного айди.
Я хочу сделать у своего проекта in-memory базу данных. Просто таблицы без связей, которые при старте приложения загружаются из текстовых файлов. Таблицы эмулируются банальными словарями, где айдишники это ключи, а значения - объекты. И потом я из этой "базы данных" читаю строки. Когда с обычной базой данных работаешь, ты создаёшь копию такого объекта (строки) у себя в приложении. А в моём варианте, чтобы не копировать ссылку из моих словарей на один и тот же объект, нужна операция клонирования. И т.к. связей между "таблицами" у меня нет, то и циклов у меня нет. В обычных БД, в ORM, вопрос с цикличностью решается ленивой загрузкой, насколько я знаю. Ну и программист сам определяет, насколько глубоко он там связи между таблицами запросит.
Чуваки из игрового мира не привыкли заморачиваться базами данных на клиенте. И в чём-то они правы - возиться ещё с ними. А в Дотнете такой удобный механизм LINQ to objects, да ещё типизированный - очень похожий на LINQ to entities, который используется для БД. И раз уж всё равно объекты сериализовать надо (сохранения, загрузки состояний), то убью двух зайцев одним ударом.
А в моём варианте, чтобы не копировать ссылку из моих словарей на один и тот же объект, нужна операция клонирования
всё равно не доходит. Если это всё реадонди, то какая разница?
Я хочу сделать у своего проекта in-memory базу данных.
типа NoSQL? А зачем то самому делать? Пару строк и все работает. https://www.infoworld.com/article/3672154/how-to-use-ef-co...
Ну или типа этого https://www.litedb.org/
типа NoSQL? А зачем то самому делать? Пару строк и все работает. https://www.infoworld.com/article/3672154/how-to-use-ef-co...
Ну или типа этого https://www.litedb.org/
Я не знаю, что такое nosql, но у меня есть коллеции объектов в памяти, я их сериализую в текстовый человекочитаемый файлик, потом могу подправить его хоть в Блокноте, потом сохранить и десериализовать снова в своё приложение. Если эта штука по последней ссылке так может (особенно человекочитаемый файлик для данных таблицы), то посмотрю её. Но они предлагают какую-то свою Студию юзать для редактирования файлов. Похоже, что файлы таблиц там не человекочитаемые. И редактировать в разных текстовых редакторах я их не смогу.
Я не знаю, что такое nosql
не страшно
https://skillbox.ru/media/code/nosql-chto-eto-za-bazy-dann...
есть коллекции объектов в памяти, я их сериализую в текстовый человекочитаемый файлик
Ломит редакторы делать? Это разве удобно для пользователей?
Но тоже не вижу зачем клонирование...
Делаем словарик <ObjectType, Object>
Делаем цикл по словарю сохраняем каждый в json файл, где ключ имя файла. Для чтения наоборот: цикл по файлам, создаём объекты.
Если не огромная коллекция то можно и всё сразу выгрузить в один файл.
litedb - не для этого
Я не знаю, что такое nosqlне страшно
https://skillbox.ru/media/code/nosql-chto-eto-za-bazy-dann...
Да не, не так. - Я не хочу знать, что такое nosql. )))
Делаем цикл по словарю сохраняем каждый в json файл, где ключ имя файла. Для чтения наоборот: цикл по файлам, создаём объекты.
Если не огромная коллекция то можно и всё сразу выгрузить в один файл.
Не, мне лучше, чтобы на одну таблицу один файл. Мне проще даже не джейсон, а csv. Типа такого
id,name,race,age
0000,Alex,human,50
0001,Malex,thuman,100500
Но для csv надо будет писать свой сериализатор-десериализатор, а для джейсона уже всё есть.
Редактор пока не нужен. Ну или хватит текстового. Ну или тупо список объектов в датагрид загрузить с возможностью редактирования их свойств через редактирование ячеек датагрида.
Он имеет ввиду, что при клонировании ссылки на объект восстанавливаются как ссылки, а не как объекты со своими полями. Но при сериализации и десериализации ссылки теряются, т.к. уже может не существовать объект, на который ссылаются. Либа по джейсону, что я предлаг, может сохранять ссылки.
Сама идея сериализации - мы вытаскиваем какой-то объект или граф объектов из контекста и разрываем все свази этого графа объектов с контекстом. При десериализации мы восстанавливаем данные графа, но не его связи с контекстом, т.к. обычно уже сам контект либо поменялся, либо уже не существует. Поэтому пре сериализации нет смысла сохранять все ссылки, а только те, что связывают объекты в сериализуемом графе.
Мне надо создать копию объекта без потери контекста, т.к. я генерю её тут же - контекст не успевают измениться. Но я создаю копии лишь данных, а не ссылок. Новую копию я ввожу в контекст, создавая для неё свои ссылки, а не копируя ссылки оригинала. В частности, я генерю для копии новый айдишник. И теперь это копия лишь в смысле данных, но ссылаться на неё нужно уже по своему уникальному айдишнику.
Таблицы эмулируются
-----
Нахрена?
Таблица, со всей функциональностью, уже есть.
Делаешь ее строго типизированной и забываешь об 95% проблем.
Мне надо, чтобы сохранённый вариант был человекочитаемый и достаточно легко редактируемый в текстовом редакторе типа Блокнота. Джейсон не нравится тем, что он некомпактный - даже несколько десятков записей будут требовать много скроллинга для просмотра. А вот формат csv очень даже компактный - можно эти несколько десятков уместить на один экран.
Тогда согласен. Просто я думаю о своём, а у меня данные компактные. Единственное что, в csv вроде только один символ-разделитель можно сделать. И даже если это будет таб, то столбцы всё равно неровными могут быть. Два таба в качестве разделителя вроде нельзя. Хотя, там стандарта на разделитель нет - как считывающий код сделаешь, так и будет... Вобщем, csv - компромиссный вариант. Но он мне в любом случае не нужен, т.к. генерить его надо ручками, а не автоматом натравил либу на класс и она всё сериализировала почти как надо, без расстановки атрибутов и громождения конфигураторов.
Мне надо, чтобы сохранённый вариант был человекочитаемый и достаточно легко редактируемый в текстовом редакторе типа Блокнота.
А вот формат csv очень даже компактный - можно эти несколько десятков уместить на один экран.
Уместить-то может быть и можно (хотя зависит от длины хранимых данных), а вот найти нужное поле или не дай бог редактировать - это трэш.
Датасет же ин-мемори коллеция данных, а не на диске. Т.е. к нему нужно иметь внешнее хранилище так и так. И ещё нужна отдельная прога для поддержки датасетов и редактирования через них данных - чтобы хотя бы грид с возможностью редактирования показала.
И датасет это не один файл, а кучка (минимум 4, вроде, на которые разваливается .xsd), описывающих один датасет.
У датасета и дататейбл из всей нужной функциональности - поддержка IList, IEnumerable и сериализации в XML. Сериализовать POCO в XML или джейсон можно и так из коробки. И загнать свои данные во что-то IEnumerable или IList я тоже легко могу - банальный словарь. И затем запрашивать их с полной функциональностью sql-подобных запросов LINQ to objects. Тогда зачем мне вся эта инфраструктура датасетов, если поддерживать её сложнее, и редактировать быстро извне в простой сторонней программе типа Блокнота нельзя?
Датасет же ин-мемори коллеция данных, а не на диске.
Именно так.
Т.е. к нему нужно иметь внешнее хранилище так и так.
Храни как хочешь. Хоть в XML :)
И ещё нужна отдельная прога для поддержки датасетов и редактирования через них данных - чтобы хотя бы грид с возможностью редактирования показала.
Зачем? :) Если в ТЗ такого нет, то не нужна. А если в ТЗ есть, то ты и со своими классами должен эту прожку написать.
И датасет это не один файл, а кучка (минимум 4, вроде, на которые разваливается .xsd), описывающих один датасет.
WriteXML создает одни XML файл. А ReadXML (внезапно) этот XML читает и воссоздает DataSet.
Тогда зачем мне вся эта инфраструктура датасетов
Если тебе нужна лайт BD, то DataSet оптимальное решение. А еще DataSet можно подружить с твоим любимым EF и вообще кайф :D
редактировать быстро извне в простой сторонней программе типа Блокнота нельзя?
Ну конечно можно. XML вполне себе поддается редактированию блокнотом :) А еще можно там искать данные при помощи XPath
и менять только то, что надо :D :D :D