data relations - как?

[bw_left]

я уверен что ни у меня одного такая мысля приходила в голову - грамотного решения пока не нашел:

есть Пользователи, есть Группы. Реализовано на valueObjects. Для упрощения предположим, что пользователь может находиться только в одной группе и группа в группу вложена быть не может). Связь идет по group_id.

Добавляя группу к пользователю, очень хочется, имея на руках экземпляр Пользователя , иметь полный доступ к его Группе (читай - к свойствам группы) и наоборот.

Как это реализуется? Может кто-то уже делал?

[Волгоградец]

И что мешает держать список групп и по айдишнику найти необходимую?

[bw_left]

ну в данном случае итерация по коллекции конечно никак не скажется, но связи-то могут быть очень большими и вложенными

хочeтся некое подобие ORM - я думаю кто-то уже что-то сделал похожее - потому что это первое, с чем сталкиваешься при таком богатом функционале DataServices

[NePridymal]

Не уверен что до конца правильно понял вопрос, но если все-таки правильно понял то вот такая мысль:
- дерево рулит!
Вот у меня была недавно задача по работе с альбомами и фотографиями в них. Могла быть вложенность любой глубины, в одном альбоме на одном уровне вложенности могли находиться как фотографии так и другие альбомы.
Дерево было построено на основе ValueObject "УзелДерева" , который мог иметь тип "фото" или "альбом" . Все узлы содержали ссылку parent (ссылку на каталог на уровень выше), так же "альбом" содержал ArrayCollection "узлов" которые находятся в нем. Для хранения использовал XML

вот как-то так.
Или я неправильно вопрос понял?

[bw_left]

нет - ситуация не такая. С XML-ем сам деревья строил - там все просто, но не всегда XML подходит - пример в посте со схемами , когда объект должен сождержать не только данные а еще и функционал какой-то. И т.к. ветвистость небольшая, растаскивать объект на данные и методы смысла особого нет - сложно очень отследить dataFlow будет.

тут задача именно подцепить один экземпляр к другому. Дело в том, что это может быть не только VO а какой-нибудь сформированный UI.

[BeDLiNt]

Ну сделайте новое проперти у персоны которое будет содежрать ссылку на группу. У группы можно сделать тоже проперти persons которое будет содержать всех персон этой группы. Ну это само собой уже не VO, а расширенные от VO модели персон и групп в которые вы добавляете необходимый функционал для работы вашего клиента.

[bw_left]

щас именно так и сделано. Создан дополнительный класс, отвечающий за relations, а в VO (который расширение от базового) добавлены необходимые properties.

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

[wvxvw]

Если чесно, то я придерживаюсь мнения, что ORM - это попытка скерстить жирафа с носорогом. Ну или как минимум, неразрешимая задача, при решении которой какой-нибудь из участков так или иначе пострадает. Хотя, конечно, это вкусовщина.
Если возможно, я бы шел по пути кастомной сериализации, и решал бы это на уровне создания кастомной коллекции + кастомного вью, которое бы делало десериализацию с учетом ссылок на уже имеющиеся объекты, структуру и т.п. Т.е. При таком раскладе то, что называется бизнес объектами или велью объектами вообще не нужно. Вы получаете на клиенте какое-то подобие обычного результата SQL запроса и уже создаете / дополняете вашу коллекцию как сочтете нужным. Кроме того, я думаю, что даже если решения в этой области существуют, то любое более-менее универсальное решение будет сильно страдать от избытка ненужного функционала. И, если быть чесным, то решений таких мне не попадалось, ну, не в открытом доступе по крайней мере.

[bw_left]

ну у меня есть моя реализация - она очень небольшая, асинхронная и быстрая - практически никаких итераций и все как у взрослых ORM (имею богатый опыт с SF + Doctrine) .... только я стесняюсь ее показывать