Дизайн класса для сериализации - идеи или шаблоны?

Question

Позвольте мне начать с иллюстративного примера (предположим, что реализация выполняется на языке со статической типизацией, таком как Java или C #).

Предположим, что вы создаете систему управления контентом (CMS) или что-то подобное. Данные иерархически организованы в Folder с. В каждой папке есть коллекция детей; ребенок может быть Page или Folder. Все элементы хранятся в корневой папке. Циклы не допускаются. У нас есть ациклический граф.

Система будет иметь удаленный API, и экземпляры Folder и Page должны быть сериализованы / десериализованы по сети. При типичной реализации папки, в которой дочерние элементы папки равны List, сериализация корневого узла отправит весь граф. Это недопустимо по очевидным причинам.

Мне интересно слышать, что люди решали эту проблему в прошлом.

У меня есть два возможных предложения:

1. Навигация по запросу : измените модель домена, чтобы класс папок содержал только список идентификаторов для каждого дочернего элемента. Чтобы получить доступ к ребенку, мы должны запросить его. Сериализация теперь тривиальна, так как граф заканчивается в четко определенной точке. Основным недостатком является то, что мы теряем безопасность типов - идентификатор может быть для чего-то, кроме папки / child.
2. Остановка и повторное присоединение : при остановке сериализации при обнаружении ссылки на папку или страницу вместо этого отправьте идентификатор. При десериализации мы должны затем найти соответствующий объект для каждого идентификатора и повторно прикрепить его в соответствующей позиции в зарождающемся объекте.

Answer 1

Я не знаю, какой API вы пытаетесь создать, но ваше предложение №1 звучит так, как будто оно близко к тому, что рекомендуется для сервисов и API в стиле REST. По сути, объект Folder будет содержать список URL-адресов своих дочерних элементов.

Answer 2

Классическим решением, вероятно, является использование шаблона прокси , где часть графика отправляется по сети, а некоторые папок заменяются прокси, у которых не будет своих списки детей, населенных до их запроса. Обращение к серверу занимает значительное количество времени и, вероятно, приведет к слишком большому количеству запросов, если все папки являются прокси-серверами (это будет выдавать новый запрос при каждой проверке содержимого папки), поэтому вы хотите перейти к некоторый компромисс между размером каждой порции данных и количеством запросов к серверу, необходимых в типичном сценарии. Это, конечно, зависит от приложения, но отправка содержимого всех дочерних папок, например, на глубину 2, может быть полезной стратегией ...

Короткая история : что, вероятно, будет работать лучше всего, это ваше решение № 1, за исключением того, что вы хотите отправлять более одной папки за раз из-за накладных расходов при двусторонней передаче на сервер. ..

Answer 3

Я бы не делал это методом Навигация по запросу. Просто потому, что я хотел бы придерживаться модели домена, где папки содержат папки или страницы.

Настройка сериализации также может быть сложной, подверженной ошибкам и сложной для изменения \ понимания.

Я бы предложил ввести в вашу модель объект типа FolderBowser, который берет идентификатор и выдает список содержимого папки. Это упростит ваши сервисные операции.

Ура, Unmesh

Answer 4

Для NFS было использовано решение Навигация по запросу . Прочитав ваш вопрос, мне кажется, что вы пытаетесь реализовать какую-то файловую систему самостоятельно.

Если вы ищете специально для отправки объектов по сети, всегда есть CORBA . Помимо этого есть DCOM и более новый WCF . Но подождите, это больше похоже на RMI . Кроме того, есть Веб-сервисы . Я остановлюсь здесь сейчас.

Answer 5

Предположим, вы моделируете все дерево, где каждый элемент является узлом, специализация узла - папка и, лист, мм У вас есть «корневой» узел. Узлы имеют методы

canHaveChildren() 
getChildren() 

Конечные узлы имеют очевидное поведение (даже не нужно подключаться к сети)

Папки getChildren() получают следующий набор узлов.

Я разработал систему с сервисами Restful по этим направлениям. Казалось бы, достаточно легко программировать.