modПонятно я как-раз на VB .NET программю
У меня задача такая:
От класса порождать потомки(несколько уровней) постепенно добавляя свойства, затем всё это безобразие выводить в TreeView.
Реально её решить с помощь Fast Object?

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

Alexey Rovdo shuklin
А какие ограничения нужно соблюдать, чтоб потом все работало без побочных эффектов?

Ну на такой общий вопрос могу только переадресовать на техническую документацию. Смотрите FastObjects™ .NET Programmer's Guide .

Жаль. А я вот на подобный вопрос в контексте Cerebrum могу ответить и лично.
1. Нужно с осторожностью использовать механизм events & delegates так как они не обслуживаются ядром VNPI. Их реализация и использование в persistent классах будет на страх и риск разработчика. В этом случае желательно хорошее знание механизма сборки мусора Cerebrum (а не GAC)

2. При работе с Cerebrum придется изучить и использовать механизм реализуемый интерфейсом IConnector. Чтобы обойти проблему, которую мы обсуждали ранее, в Cerebrum вместо указателей используются идентификаторы объектов. Чтобы получить указатель на .NET экземпляр persistent объекта необходимо используя NativeHandle и интерфейс IContainer получить указатель на интерфейс IConnector. В свойстве Component этого интерфейса можно взять указатель на пользовательский persistent объект.

Это самые основные by design ограничения API Cerebrum.

vadiminfo shuklin
Их реализация и использование в persistent классах будет на страх и риск разработчика.

Если Вы хотели обрадовать этим разработчика, то я думаю Вам это удалось.

В отличии от некоторых, я горжусь своими ограничениями. Дай им удачи не хуже иметь

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

modно увы мне нужна коммерческая версия СУБД...
Суть моего исследвания в том, что эффективно ли внедрить систему основанную на ООСУБД на предприеятие...

Вот тут приходится развести руками. Научно-исследовательская разработка однако. Текущую версию в практических сценариях могу рекомендовать толкько как ембидет в приложения, хранящие данные в локальных файлах.

modУгу, в динамическом режиме, в том и жуть.... Я реализовал задачу в Ms SQL, но там пришлось расчленять классы, объекты и свойства по таблицам. Получились таблицы хранящие классы и подклассы, свойства и пр. Оно работает и вроде даже в ФНБК вписывается, но как-то некрасиво. Поэтому ищу способ без расчленёнки.... Я уже и понял что не подходит...

Если не нужен многопользовательский доступ и все приложение реально развренуть только на одном PC - даже для пром применения рекомендую обратить внимание на мое поделие. Оно как раз и под такие проблемы измышлялось. Если нужен многопользовательский доступ или распределенная система - или ищите другие варианты, или подождите пока я допилю свою БД , или еще остается возможность использовать .NET Remoting для доступа по сети к БД Cerebrum

modимею ввиду что неполучится компилировать...
Сделайте тогда класс - значение аттрибута. И в базовом классе для всех своих классов держите коллекцию экземпляров этих аттрибутов. Для таких фишек ОБД как раз самое то. И компилить не надо. И объект будет всегда по прямому указателю со всеми своими аттрибутами доступен.

ModelR shuklin modимею ввиду что неполучится компилировать...
Сделайте тогда класс - значение аттрибута. И в базовом классе для всех своих классов держите коллекцию экземпляров этих аттрибутов. Для таких фишек ОБД как раз самое то. И компилить не надо. И объект будет всегда по прямому указателю со всеми своими аттрибутами доступен.
И получиться у Вас классический случай EAV модели, и нафига тогда связываться с ООБД, когда все ложится в 4 таблицы? :)

1. Их тогда не придется переливать в классы. Одна проблема исчезла. Я не говорю что маппинг уш очень большая проблема. Но решение проблемы и отсутствие проблемы - две большие разницы.

2. не нужно проводить JOIN аттрибутов с объектами - аттрибуты и так уже являются частью объекта.

3. Можно сделать базовый класс для аттрибута и унаследовать от него классы текстового атрибута, целого, даты-времени, указателя на другой объект ... Вот тут уш классические РБД без sql_variant отдохнуть в качественном плане.

ИМХО первая причина самая веская. Зачем нужны лишние сущности в виде таблиц и реляционной базы, если реализация все равно будет вестись на .NET в стиле ООП?

PS. А зачем целых 4 таблицы? можно ведь и одной обойтись

it depends
Зачем нужны воопче нафик субд (неважно какие "О", "Р", "ОО", "XML") - периодицкий дамп всей памяти на диск и рестор с нее - и фсё.

Ващето это как раз та цель, к которой стремятся ООСУБД. Стереть грань между дисковой памятью и RAM. Есть просто классы и объекты, методы у объектов просто выполняются. Независимо от рестартов оборудования и приложений. Никаких файлов с документами, электронными таблицами - все всегда запущено и всегда в памяти. Все приложения всегда в памяти. Все документы всегда загружены. Все многопользовательские конфликты разруливаются аффтоматом ... лепота.

U-gene Ващето это как раз та цель, к которой стремятся ООСУБД.Ващето это цель уже давно достигнута РСУБД :)

неужели? В какой существующей РСУБД я могу в строке таблицы реализовать интерфейс или виртуальный метод? в каком году это появилось в этой РСУБД?