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

Вот вам и полиморфизм.

Решил поднять тему, так как кое что изменилось за последнее время.

В данный момент совсем нет времени заниматься системой.
Все остановилось на полушаге от готовности.

1. Почти что есть автоформы, достаточно посидеть один-два дня и все будет готово, но взять эти два дня негде.

2. Последнее время была реализована система разделения прав.

3.Была переписана система папок для хранения объектов, теперь объект может находится не в одной, как раньше а в нескольких папках, хоть во всех.

4.Была реализована система поиска объектов на основе метаданных.

Еще хотелось бы реализовать:
1. Систему скриптования объектов (и классов в том числе)

2. Класс таблица - для создания и изменения таблиц через интерфейс с учетом версионности и при наличии данных в таблице.

3. Создать класс процедура - для создания и модификации хранимых процедур тоде через интерфейс системы и тоже с учетом версионности.

4. Класс проект, через который определять версионность предыдущих объектов.

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

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

Да никаких проблем. В вашем распоряжении вся мощь сервера MSSQL2000
К одному объекту можно привязать неограниченное количество таблиц. По созданию процедур ограничений тоже никаких.

Пример создания вышеперечисленных сущностей.

1. Константа
Определяем сущность - например, настройки. Для интерфейса таблиц создавать не надо. Наименование будет в таблице Objects, наследуем от класса DBObject.
Для хранения констант заводим таблички
Constant_Names
(
OID int,
ID int identity,
Constant varchar(32),
Name varchar(128),
primary key clustered ( OID, ID )
)

Constant_Values
(
ID,
Date,
Value varchar(255)
)

создаем 4 процедуры для подтаблички объекта.

В результате в интерфейсе видим объект класса DBOSettings с наименование "Настройки"

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

2. Справочник уже есть с иерархией, причем множественной, если от справочника нужно только наименование и идентификатор, то достаточно зарегистрировать новый класс, можно прямо через интерфейс. Если необходимы еще поля, создаем таблицу по аналогии выше. таблица может быть связана как один-к-одному, тогда доп.атрибуты будут в шапке формы либо как многие-к-одному, тогда это будет грид в закладке. Закладок можно создавать сколь угодно много, в пределах разумного.

3. По документу тоже самое.

4. И т.д. и т.п.

Система прав представляет собой матрицу Object, Method, User
Под методом подразумевается форма. Формы бывают всякие, какие зарегистриешь такие и будут. В разрезе атрибутов не делал, не вижу необходимости. Проще отдельными формами контролировать.

Каждый отдельный пользователь имеет логин для доступа со своими правами.
Все пользователи имеют доступ на выполнение только хранимых процедур. Адимнистратор имеет полный доступ.

Объект - это запись в таблице Objects, папка наследуется от объекта и имеет доп. таблицу Folder_Objects ( OID, ObjectOID ), соответсвенно в любую папку можно поместить сколько угодно объектов. Есть еще таблица FolderTree, в которой хранится развернутая иерархия папок. По ней можно быстро определить имеет ли отношение к папке объект. То есть хранится запись принадлежности объекта папке, ее родителя, родителя ее родителя и так до верху. Это позволяет не делать обходы деревьев.

Так_забежал_простоСмущает то, что система, похоже, упрощает только проектирование клиентской части приложения. Что же касается серверной части - тут всё, наоборот, становится только хуже.
1) Для каждого нового класса приходится писать методы создания, удаления, редактирования. Вроде, так, или я не прав?
2) Основная писанина в нормально спроектированном приложении происходит на сервере. Вот и вопрос - эта самая объектность на сервере как-то видна? Или просто заключается в неком наборе соглашений по именованию ХП? До сих пор здесь были приведены только примеры работы с объектами из клиентской части. Всё, что на сервере - использует обычные инсёрты, апдейты и т.д.

Для меня никогда не было проблемой писать серверный код, но всегда доставало при этом на каждый чих описывать клиентские изменения/дополнения. К тому же если нет стандартного способа доступа клиента к серверу, то отслеживать какие-то ограничения затруднительно.
Кто-то с клиента через ХП работает, а кто-то напрямую. Ядро эту часть берет на себя. Здесь даже формы создавать не нужно, хотя это и не закрыто специально.

Объектность на сервере именно в виде различных соглашений. Это правила создания таблиц, процедур, правила их наименования и использования. Чтобы получить истинную объектность с инкапсуляцией, нужно создавать ООЯ с компилятором, который переводил бы ОО-код в T-SQL, это не сложно, но на это нужно время и деньги. Да и смысла в этом сейчас уже нет, так как есть Cache.

Для создания простых процедур типа select/insert/update/delete делаю генератор, но далеко не всегда у сущностей эти методы простые, так что
от необходимости писать серверный код Вас это не избавит.

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

Кроме того это дает полиморфизм. Допустим, описываем класс документ (абстрактный) и в нем метод ИзменитьСтатус. В этом методе пишем динамический вызов хранимой процедуры конкретного класса определив его по идентификатору, являющемуся аналогом This/Me/Self. А процедуру ИзменитьСтатус дергает какой-то другой механизм, ничего не знающий о наследниках документа.

Сейчас я работаю с похожей системой. Это полноценная ЕРП система с сервером MSSQL2000 и клиентом на С++. Пишем только на T-SQL.
Недостатки на мой взгляд отсутствие полноценного наследования, хотя в какой-то мере оно есть. И нет полиморфизма, как раз из-за отсутствия типизации. Но тем не менее эта система стоит почти на всех пивзаводах бывшего СССР.

Так_забежал_просто
Если нет смысла - тогда зачем вообще Ваше объектное ядро? Перечислите Ваши цели и задачи. И что конкретно упростилось с появлением этого ядра. При этом соглашения об именовании ядром я бы не считал - это, скорее, инструкция по проектированию системы в объектных терминах, а ядро и инструкция - вещи разные. Все вызовы методов из клиента в этом "ядре", по-моему, можно заменить на прямые вызовы соотв. процедур - ничего не изменится.

Цель - облегчить разработку интерфейса.

Так_забежал_простоНет. Это не полиморфизм. Опять-таки, это инструкция по реализации полиморфизма. Вы в дельфях каждый раз описываете такой метод, забабахиваете в него begin if ClassName = 'class1' then class1(Self).DoSmth ... ?

Это можно легко сделать с помощью макроса. Я имею ввиду прекомпилятор для T-SQL

У меня тоже есть знакомые, которые аналогичные вещи сделали.

1. NEXUS. Автоформы, все на T-SQL в ОО стиле

2. Ontario. Все в ОО стиле без метаданных

3. A2. Полностью на метаданных, полноценное ОО, но без клиента

4. MonolitSQL. Собственная среда разработки. Неполноценное наследование, отсутствие полиморфизма.

Все эти системы имеют инстансы в организациях. И вполне успешно работают.

Я пытаюсь вобрать все самое лучше.

Здесь есть устаревшее описание. Но клиент почти не изменился.

http://dbobjects.narod.ru

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

1. Генератор процедур не готов, так как я сейчас доделываю более нужные вещи.
Хотя генератор я однажды уже делал и с серверным кодом и с клиентским, где-то валяется, но он не имеет ценности пока не сделаю единую среду разработки.

2. Не понял, что значит вручную? Есть механизм назначения прав, ядро используя этот механизм определяет, что давать пользователю, а что нет.
Прикладному программисту ничего для этого делать не нужно.

3. Причина есть. Это невозможность дать ограничение на доступ к записи. У меня же каждый объект является записью, соответственно на каждую запись (объект) можно дать право на различные действия различным пользователям.

Система не имеет абсолютной защиты. Разграничение прав выполняет клиент, проверяет какие формы можно показывать пользователю.