Честно говоря, не знаю к кому обратиться с таким вопросом:

Существует некий класс А, который имеет свойство "Мой друг" типа Object.
Значением данного свойства могут быть объекты типов B, C и D ...
Другими словами реализуется множественность значений свойства объекта.

Подскажите, пожалуйста, какие ORM framework'и реализуют такую возможность?

Здравствуйте, Dimsen, Вы писали:

D>Существует некий класс А, который имеет свойство "Мой друг" типа Object.
D>Значением данного свойства могут быть объекты типов B, C и D ...
D>Подскажите, пожалуйста, какие ORM framework'и реализуют такую возможность?

Да все практически.
В BLToolkit для этого можно задействовать, например, фабрику объектов.

Лично я вот прямо сейчас решаю подобную задачу через хранение доп. свойств в виде XML и "домапливаю" специфичные поля ручками.
Если идея разовьётся во что-то законченное и красивое — выложу.

Здравствуйте, Блудов Павел, Вы писали:

БП>Да все практически.
Я имел ввиду когда не нужно ничего домапливать или допрограммировать,
а framework сам все разруливает согласно заложенной в него (или неё ???) системы правил.

БП>В BLToolkit для этого можно задействовать, например, фабрику объектов.

Если я правильно догоняю, то здесь используется специальное вспомогательное поле, указывающее реальный тип объекта.

БП>Лично я вот прямо сейчас решаю подобную задачу через хранение доп. свойств в виде XML и "домапливаю" специфичные поля ручками.
БП>Если идея разовьётся во что-то законченное и красивое — выложу.

Мое видение этой проблемы такое — есть два варианта решения проблемы:
1. вспомогательное поле с указанием типа объекта,
2. реализация паттерна типа "Реестр" ...
Другие варианты пока в голову не приходят ... только вот как еще объяснить мапперу, что данное поле является ссылкой на объект, который может быть разных типов ??? Я исхожу все-таки из того, что маппер достаточно умный, чтобы дописывать его вручную для каждого типа индивидуально, хочется все-таки иметь некую универсальность решения

Здравствуйте, Dimsen, Вы писали:

D>Если я правильно догоняю, то здесь используется специальное вспомогательное поле, указывающее реальный тип объекта.
Нет. Поле указывает тип фабрики объектов. Реализация фабрики Ваше личное дело.
Я у себя тупо храню в каждом поле полное имя типа объекта (иногда вместе с именем сборки). Вот кусок кода, создающий объекты:

            public object CreateInstance(TypeAccessor typeAccessor, InitContext context)
            {
                // Get the object type indicator field.
                //
                string objectTypeName = (string)context.DataSource.GetValue(context.SourceObject, "ReportDimType");

                if (string.IsNullOrEmpty(objectTypeName))
                {
                    context.ObjectMapper = ObjectMapper<ReportDimension>.Instance;
                }
                else
                {
                    Type dimType;
                    string libFileName = (string)context.DataSource.GetValue(context.SourceObject, "LibFileName");

                    if (string.IsNullOrEmpty(libFileName))
                    {
                        dimType = FindType("Sopstk.Core.dll", objectTypeName);
                        if (null == dimType)
                            dimType = FindType("CBossReports.dll", objectTypeName);
                    }
                    else
                        dimType = FindType(libFileName, objectTypeName);

                    Debug.Assert(null != dimType && typeof(ReportDimension).IsAssignableFrom(dimType));

                    context.ObjectMapper = Map.GetObjectMapper(dimType ?? typeof(ReportDimension));
                }

                // Create an object instance.
                // Do not call ObjectMapper.CreateInstance as it will lead to infinite recursion.
                //
                return context.ObjectMapper.TypeAccessor.CreateInstance(context);
            }

Здравствуйте, Блудов Павел,

Спасибо за ответы, но все же хотелось бы более универсального маппера.
1С подобную проблему решила еще лет 7 назад и достаточно успешно ...
Конечно же не совсем корректное сравнение, но тем не менее ...

Просто лично я хотел бы, чтобы можно было делать вот так:
BisnessObject bo = SomeManager.GetObjectByID(id);
Type t = bo.MyBestFriend.GetType();
и переменная бы t содержала конкретный тип данных ...

Здравствуйте, Dimsen, Вы писали:

D>Спасибо за ответы, но все же хотелось бы более универсального маппера.
D>1С подобную проблему решила еще лет 7 назад и достаточно успешно ...

Для того, чтобы получить тип данных объекта, получаемого из неизвестного источника, нужно, чтобы в приезжаемых данных можно было за что-то зацепиться. Чудес не бывает То, что 1С решает эти проблемы, так наверняка у них такие данные в каком-то виде есть, т.к. база данных в 1C имеет структуру специально заточенную под 1С. В частности, наверняка, если 1С допускает сохранение данных для разных объектов в одной записи, то какой-то идентификатор типа там должен присутствовать.

Тоже самое можно сделать и в случае bltoolkit. Т.е. можно найти универсальное в пределах конкретной задачи решение.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Dimsen, Вы писали:

D>>Спасибо за ответы, но все же хотелось бы более универсального маппера.
D>>1С подобную проблему решила еще лет 7 назад и достаточно успешно ...

IT>Для того, чтобы получить тип данных объекта, получаемого из неизвестного источника, нужно, чтобы в приезжаемых данных можно было за что-то зацепиться. Чудес не бывает То, что 1С решает эти проблемы, так наверняка у них такие данные в каком-то виде есть, т.к. база данных в 1C имеет структуру специально заточенную под 1С. В частности, наверняка, если 1С допускает сохранение данных для разных объектов в одной записи, то какой-то идентификатор типа там должен присутствовать.

IT>Тоже самое можно сделать и в случае bltoolkit. Т.е. можно найти универсальное в пределах конкретной задачи решение.

Совершенно согласен, просто, в рамках заданного мною в первом посте вопроса, интересно узнать чужое мнение относительно наиболее эффективного варианта для решения поставленной задачи, при этом универсальность решения играет не последнюю роль. Например, в той же 1С эта задача решена крайне неэффективно (зато максимально универсально): там присутствует понятие составного типа данных (по сути дела VARIANT). Для хранения одного значения такого типа отводится 7 (!!!) полей таблицы базы данных: одно поле описывает тип данных, четыре поля могут хранить значение примитивного типа данных (число, строка, булево и дата), еще два поля отводятся для хранения ссылочного типа данных. Т.е. получается, что для хранения ссылочных типов данных используется три поля, хотя вполне достаточно было бы иметь два: идентификатор типа и непосредственно ссылка. При всем при этом 1С использует суффиксы в названиях полей таблиц базы данных.

Если говорить в общем и целом о, так сказать (не побоимся этого слова) паттерне данной задачи (Reference Resolver), то напрашивается вывод, что в основном используется поле-идентификатор типа, например: поле "ANIMAL" хранит ссылку на объект типа описываемого в поле "ANIMAL_TYPE". Вопрос также заключается и в том, есть ли более эффективный способ решения задачи (см. первый пост)? Как я уже писал, возможным вариантом решения проблемы может быть реализация паттерна "Реестр", где одна таблица имеет два поля: ссылка на объект + описание типа. Недостатком первого варианта является увеличение объемов данных, а второго варианта — потенциально огромный размер таблицы разрешения ссылок, а, следовательно, замедление процесса разрешения ссылок.