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

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

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

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

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

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

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