Comments 11
Можете озвучить практический смысл и примеры в которых полезно это использовать?
Полезно было использование в рамках проектов, где не требуется использование баз данных, а хранить данные (объекты) необходимо в открытом формате xml. Вдобавок, довольно удобно располагаются файлы с объектами и открытый формат xml позволяет обрабатывать эти объекты (и файлы) сторонними приложениями.
В сторону Apache Avro не смотрели? Если смотрели, то как по-вашему необходимый функционал отличается?
У трехколесного велосипеда обычно три колеса.
Для удобного хранения java объектов в xml я использовал XStream, который вполне удобно и прозрачно выполняет сериализацию/десериализацию с учетом вложенности java объектов в/из xml (или JSON или еще другой, при наличии класса парсера)
xstream довольно удобный в плане сериализации объектов и небольшого количества файлов. В этой разработке поддержание сложной структуры файлов с объектами берет на себя сама библиотека. При этом операции добавления и удвления объектов выполняются довольно быстро. В этом и стояла задача при разработке. Решил выложить и написать поскольку может пригодится. Меня она дважды выручала уже.
То что автор решил попрактиковаться в проектировании и программировании библиотеки — это похвально. Если есть свободное время и желание, почему бы и нет. Опыт лишним не будет.
Что не понравилось в библиотеке:
1) То что все операции надо выполнять явно. Хотелось бы как в хибернете, открыл транзакцию, загрузил обьекты, модифицировал их — закрыл транзакцию — и все изменения сохранились в базу. Без явных вызовов update.
2) В сериализованном виде isNull=«false» — загрязняют файлы. Нельзя ли просто если не задано value то считать что в поле null?
3)
Дублирование id. Можно или убрать из рутового обьекта или убрать поле.
4) Поля сериализуются в object, с атрибутом name, так же как и рутовые объекты. И в то же вермя есть особый тег collection… Я бы все поля сериализовал через field. Коллекция или нет различал бы по классу.
5) Вместо IXmlDataStoreIdentifiable использовал бы абстрактный класс DataStoreObject с полем dataStoreId. Абстрактный класс — чтобы не заставлять пользователя библиотеки каждый раз создавать это поле и геттер/сеттер для него. Название поле не id — т.к. id может уже быть в классе и использоваться для других целей.
6) Искусственное разделение на root и не root объекты. Это уже детали реализации библиотеки и пользователю не обязательно о них знать. Для него должно быть просто — CRUD операции над объектами наследниками DataStoreObject.
7) Не возможно искать обьекты в базе по атрибутам (кроме id), я уже не говорю о сложных запросах типа sql.
8) Использовал бы в качестве id инкрементируемый счетчик int. Случайные строки — слишком заумно.
Что не понравилось в библиотеке:
1) То что все операции надо выполнять явно. Хотелось бы как в хибернете, открыл транзакцию, загрузил обьекты, модифицировал их — закрыл транзакцию — и все изменения сохранились в базу. Без явных вызовов update.
2) В сериализованном виде isNull=«false» — загрязняют файлы. Нельзя ли просто если не задано value то считать что в поле null?
3)
<object isNull="false" class="org.flib.xdstore.entities.XdGalaxy" id="cc74e3f2">
<object name="Id" isNull="false" class="java.lang.String" value="cc74e3f2"/>
</object>
Дублирование id. Можно или убрать из рутового обьекта или убрать поле.
4) Поля сериализуются в object, с атрибутом name, так же как и рутовые объекты. И в то же вермя есть особый тег collection… Я бы все поля сериализовал через field. Коллекция или нет различал бы по классу.
5) Вместо IXmlDataStoreIdentifiable использовал бы абстрактный класс DataStoreObject с полем dataStoreId. Абстрактный класс — чтобы не заставлять пользователя библиотеки каждый раз создавать это поле и геттер/сеттер для него. Название поле не id — т.к. id может уже быть в классе и использоваться для других целей.
6) Искусственное разделение на root и не root объекты. Это уже детали реализации библиотеки и пользователю не обязательно о них знать. Для него должно быть просто — CRUD операции над объектами наследниками DataStoreObject.
7) Не возможно искать обьекты в базе по атрибутам (кроме id), я уже не говорю о сложных запросах типа sql.
8) Использовал бы в качестве id инкрементируемый счетчик int. Случайные строки — слишком заумно.
0) Спасибо за содержательную критику и пожелания. При появлении свободного времени займусь отдельным бранчем для реализации описанных замечаний.
1) Прозрачная сериализация не сделана намеренно. Вы работаете с клонами из кэша и поскольку явно заказываете нужный вам объект, то так же явно и указываете на то, что этот объект вы изменили.
2,3,4) Небольшое добавление касательно сериализации и различных видов полей: в библиотеке специально введена возможность сменить writer and reader. Вы можете написать свои и тем самым сменить формат, можете даже использовать json формат для сериализации. Главное чтобы эти объекты могли быть прочитаны вашей реализацией reader-а. Просто эта статья написана с первой версии.
5) Касательно абстрактного класса скажу следующее: в java множественное наследование от классов не поддерживается, поэтому в любом случае это должен быть интерфейс, а не класс, поскольку модели обычно строятся на основе шаблона Composite и наш абстрактный класс должен быть реализован в самой голове шаблона, это и плюс и минус одновременно. А вот за dataStoreId огромное спасибо, сразу на ум что-то не пришло :(
В остальном Вам никто не мешает самим реализовать этот абстрактный базовый класс.
6) Модели данных по шаблону Composite почти всегда имеют корневые объекты, для них и сделаны эти методы. Но это замечание я учту и в отдельном бранче скорее всего от этих методов избавлюсь.
7) В последних версиях 1.3 и 1.4 реализована возможность выборки объектов по различным полям с помощью интерфейса Predicate.
8) Случайные строки это еще проще, нежели счетчик: UUID.randomUUID().toString().
PS: огромное спасибо что уделили время на анализ и критику по существу. Ваши пожелания будут учтены :)
1) Прозрачная сериализация не сделана намеренно. Вы работаете с клонами из кэша и поскольку явно заказываете нужный вам объект, то так же явно и указываете на то, что этот объект вы изменили.
2,3,4) Небольшое добавление касательно сериализации и различных видов полей: в библиотеке специально введена возможность сменить writer and reader. Вы можете написать свои и тем самым сменить формат, можете даже использовать json формат для сериализации. Главное чтобы эти объекты могли быть прочитаны вашей реализацией reader-а. Просто эта статья написана с первой версии.
5) Касательно абстрактного класса скажу следующее: в java множественное наследование от классов не поддерживается, поэтому в любом случае это должен быть интерфейс, а не класс, поскольку модели обычно строятся на основе шаблона Composite и наш абстрактный класс должен быть реализован в самой голове шаблона, это и плюс и минус одновременно. А вот за dataStoreId огромное спасибо, сразу на ум что-то не пришло :(
В остальном Вам никто не мешает самим реализовать этот абстрактный базовый класс.
6) Модели данных по шаблону Composite почти всегда имеют корневые объекты, для них и сделаны эти методы. Но это замечание я учту и в отдельном бранче скорее всего от этих методов избавлюсь.
7) В последних версиях 1.3 и 1.4 реализована возможность выборки объектов по различным полям с помощью интерфейса Predicate.
8) Случайные строки это еще проще, нежели счетчик: UUID.randomUUID().toString().
PS: огромное спасибо что уделили время на анализ и критику по существу. Ваши пожелания будут учтены :)
5) Согласен. Это в скале можно было бы создать trait. и там поле с методами. И добавить его к любому классу. А джаве не получится, конечно, если класс уже наследуется от другого.
8) Имел в виду инкрементальный счетчик, т.е. для первого обьекта 1, потом 2, 3, 4. И никакого рандома.
Всегда пожалуйста :) Покритиковать чужой код всегда приятно)
8) Имел в виду инкрементальный счетчик, т.е. для первого обьекта 1, потом 2, 3, 4. И никакого рандома.
Всегда пожалуйста :) Покритиковать чужой код всегда приятно)
Sign up to leave a comment.
Много-файловое хранилище Java объектов в формате xml