Comments 9
Я бы не хотел, но придется вас огорчить.
Для хранения и передачи данных все используют DTO, поэтому хитроумные сериализаторы не нужны
Для хранения и передачи данных все используют DTO, поэтому хитроумные сериализаторы не нужны
Использование DTO — это лишь один из частных случаев в разработке.
Хотелось бы акцентировать внимание на том, что помимо сериализации библиотека предназначена для более широкого круга задач.
К примеру, имеется два DTO объекта, и их нужно сравнить. Можно, конечно, написать свою логику сравнения, но проще и быстрее сделать сопоставление снимков, как показано в статье.
Хотелось бы акцентировать внимание на том, что помимо сериализации библиотека предназначена для более широкого круга задач.
К примеру, имеется два DTO объекта, и их нужно сравнить. Можно, конечно, написать свою логику сравнения, но проще и быстрее сделать сопоставление снимков, как показано в статье.
то то и видно, как все пишут мапперы мапперов мапперов для DTO проходящих через всякие хибернейты и реакты
+ отдельный вопрос про нереляционные базы данных и управляемую денормализацию
+ отдельный вопрос про нереляционные базы данных и управляемую денормализацию
Стоит ещё отметить, что использование отдельных DTO — в некоторых случаях вынужденная мера, накладываемая ограничениями сериализаторов.
Как правило, имеется некоторая модель и её нужно передать или сохранить, но граф модели иногда может иметь довольно сложную структуру, из-за которой не получается его сразу засериализовать. Как выход, приходится выделять отдельные DTO-сущности и делать на них маппинги, генерировать большое количество однотипного кода, хотя в определённых случаях напрямую сериализовать модели вполне себе удобно и практично.
Как правило, имеется некоторая модель и её нужно передать или сохранить, но граф модели иногда может иметь довольно сложную структуру, из-за которой не получается его сразу засериализовать. Как выход, приходится выделять отдельные DTO-сущности и делать на них маппинги, генерировать большое количество однотипного кода, хотя в определённых случаях напрямую сериализовать модели вполне себе удобно и практично.
Пускай нам задан экземпляр любого объекта. В начальный момент времени мы делаем снимок его состояния, спустя какое-то время можем снимок повторить и, сопоставляя оба снимка, выявить все интересующие нас мутации, которые произошли с данным экземпляром, то есть реализовать трекинг состояния.
Еще было бы здорово при получении разницы объектов уметь накладывать ее на объект более ранней версии. Тогда можно было бы хранить начальное состояние объекта и слепки. И получать нужную версию накладывая постепенно диффы на начальный объект. Типа Event Soursing.
И было бы здорово указывать каким образом хранить сериализованный объект, json конечно хорош, но сразу в бинарном виде было бы тоже полезно. Или в бинарном сжатом. То есть добавить абстракцию для представления сериализованного вида.
Насколько понял первое пожелание — это реконструкция наоборот :)
В принципе, её можно делать и сейчас, но с некоторыми ограничениями. Для стабильных графов она будет работать очевидным образом, то есть примитивные свойства объектов (типов string, int, double, DateTime, etc.) примут значения с любого снимка.
Нюансы появятся с мутирующими графами, когда объекты удаляются и вставляются в граф. Как упоминалось в публикации, для выполнения реконструкции необходимо наличие кэша Dictionary[object, int], который содержит сами объекты, подвергающиеся реконструкции, и их уникальные идентификаторы. Если вдруг объекта не оказывается в кэше, то репликатор создаёт новый экземпляр и добавляет его в кэш (id генерируется инкрементом). Так вот, если на снимках не будет конфликтов в идентификаторах, то «реконструкция наоборот» отработает успешно, в противном случае может возникнуть исключение о несоответствии типов, или же нарушиться структура графа.
Это напоминает мерж коммитов из рабочей ветки в основную, если изменения фиксировать и накатывать последовательно, то всё мержится автоматом, но если применять коммиты вразнобой, то начинаются конфликты. Приблизительно та же ситуация и со снимками в RF.
В библиотеке изначально разделена логика трансляции снимка (ReplicationProfile) и его сохранения (KeepProfile), то есть в дальнейшем без больших затруднений можно добавить сериализацию в бинарный формат, просто на данном этапе разработки было решено ограничиться json, как наиболее человекоориентированным.
Спасибо за интерес и пожелания!
В принципе, её можно делать и сейчас, но с некоторыми ограничениями. Для стабильных графов она будет работать очевидным образом, то есть примитивные свойства объектов (типов string, int, double, DateTime, etc.) примут значения с любого снимка.
Нюансы появятся с мутирующими графами, когда объекты удаляются и вставляются в граф. Как упоминалось в публикации, для выполнения реконструкции необходимо наличие кэша Dictionary[object, int], который содержит сами объекты, подвергающиеся реконструкции, и их уникальные идентификаторы. Если вдруг объекта не оказывается в кэше, то репликатор создаёт новый экземпляр и добавляет его в кэш (id генерируется инкрементом). Так вот, если на снимках не будет конфликтов в идентификаторах, то «реконструкция наоборот» отработает успешно, в противном случае может возникнуть исключение о несоответствии типов, или же нарушиться структура графа.
Это напоминает мерж коммитов из рабочей ветки в основную, если изменения фиксировать и накатывать последовательно, то всё мержится автоматом, но если применять коммиты вразнобой, то начинаются конфликты. Приблизительно та же ситуация и со снимками в RF.
В библиотеке изначально разделена логика трансляции снимка (ReplicationProfile) и его сохранения (KeepProfile), то есть в дальнейшем без больших затруднений можно добавить сериализацию в бинарный формат, просто на данном этапе разработки было решено ограничиться json, как наиболее человекоориентированным.
Спасибо за интерес и пожелания!
Для сравнения объектов есть отличная либа https://github.com/GregFinzer/Compare-Net-Objects
Да, существует такая альтернативная библиотека для сравнения, но Replication Framework предлагает более обобщённый подход…
Например, необходимо проследить изменения в процессе жизни одного экземпляра объекта [графа]. Не всегда есть возможность сделать его точную копию в начальный момент времени, то есть у нас экземпляр только один! Чтобы воспользоваться Compare-Net-Objects необходимо на вход подать два различных экземпляра объекта, чтобы производить между ними сравнение (если же мы подадим один и тот же экземпляр, то в итоге получим равенство). Replication Framework для сравнения нуждается лишь в снимках объектов, а их можно делать в любые моменты времени без ограничений, что даёт возможность организации трекинга состояния, поскольку снимки одного и того же объекта в различные моменты времени вполне могут отличаться.
Например, необходимо проследить изменения в процессе жизни одного экземпляра объекта [графа]. Не всегда есть возможность сделать его точную копию в начальный момент времени, то есть у нас экземпляр только один! Чтобы воспользоваться Compare-Net-Objects необходимо на вход подать два различных экземпляра объекта, чтобы производить между ними сравнение (если же мы подадим один и тот же экземпляр, то в итоге получим равенство). Replication Framework для сравнения нуждается лишь в снимках объектов, а их можно делать в любые моменты времени без ограничений, что даёт возможность организации трекинга состояния, поскольку снимки одного и того же объекта в различные моменты времени вполне могут отличаться.
Также, как упоминалось в публикации, результатом выполнения операции сопоставления в RF является IEnumerable, что позволяет использовать Linq для динамического анализа результатов сравнения и значимо для производительности.
В Compare-Net-Objects можно задать пороговое количество различий, когда сравнение прекращается, после чего все они будут занесены в коллекцию public List[Difference] Differences класса ComparisionResult. Но подход с IEnumerable более гибкий, поскольку можно учитывать не только количество различий, но и другие факторы, например, их качество (насколько различие является существенным).
В Compare-Net-Objects можно задать пороговое количество различий, когда сравнение прекращается, после чего все они будут занесены в коллекцию public List[Difference] Differences класса ComparisionResult. Но подход с IEnumerable более гибкий, поскольку можно учитывать не только количество различий, но и другие факторы, например, их качество (насколько различие является существенным).
Sign up to leave a comment.
Replication Framework • глубинное копирование и обобщённое сравнение связных графов объектов