Спешу поделиться своей радостью :-)
Пишу на Дельфи и МССкуль

На сервере класс представлен таблицей и четырьмя процедурами
Open, Create, Save, Delete

имя хранимой процедуры состоит из наименования класса и вышеперечисленного, например, DBOClient_Open

На клиенте написал компонент, TDBObject, имеет методы:

Retrieve - вытаскивает все атрибуты объекта, то есть все поля всех таблиц, принадлежащих классу. Работает так: есть специальная процедура, которая по параметру @Class вытаскивает все процедуры с окончанием Open и началом имени класса, начиная от базового до текущего. Затем получив список процедур. открываем их все по идентификатору объекта @OID

Можно получить любой атрибут, написав так DBObject['Name'], можно изменить значения.

Далее есть метод Save

Он работает аналогично, вытаскиваются все процедуры сохранения объекта, названия параметров соответствуют названиям полей процедур Open, заполняются автоматически. и вызывается ExecProc

Для подчиненных таблиц объекта все очень похоже:
Названия процедур формируются так DBOMeasure_Rates_Open и DBOMeasure_Rates_Save. Имеется компонент унаследованный от хранимой процедуры, который кешированно позволяет менять данные, а при сохранении для каждой записи вызывает процедуру Save, заполняя параметры значениями из полей датасета.

К подчиненной таблице можно обратиться так:
DBObject['Rates']

В форме все выглядит так:
У формы есть методы Init и Save
В методе Init пишем

begin
inherited;
edtMeasure.OID := DBObject['MeasureOID'];
dbgRates.DataSet := DBObject['Rates'];
end;

В методе Save:
begin
inherited;
DBObject['MeasureOID'] := edtMeasure.OID;
//Rates назад присваивать не надо так как это датасет и данные меняются прямо в нем.
end;

в базовой форме после вызова метода Save, вызывается
DBObject.Save;

Для подчиненных таблиц у меня используется грид. Если постараться и написать DBAware контролы для атрибутов объекта, то можно будет форму на лету формировать. Так что вся разработка останется только на сервере.

Такое ощущение, что каждый день по нескольку таких систем пишется :-)
Просмотров много, а ответов всего два.

alex_k

1С по производительности может получится, если люди начнут логику писать на клиенте. Я сделал компонент только для того чтобы на форме его удобно было использовать (вытащить объект, изменить, сохранить).

Кроме того этот комонент можно будет превратить в COM-объект.
И тогда пишите клиента на чем хотите.

AAron

Работать с реляционными данными гораздо удобнее в реляционной базе. И работать быстрее будет

Собираюсь в дальнейшем переписать на дотНет. И базу использовать Юкон

База нужна ведь не только для того чтобы хранить объекты. Хранить их естественно гораздо удобнее в объектной базе, но вот обрабатывать списки данных эффективно можно только в реляционной, поэтому в базе у меня все реляционно, а на клиенте объектно. Самая эффективная связка.

Может конечно разработчику и не очень легко будет в этом разбираться, но пусть тогда, те кто этого не может, катяться куда подальше. :-)

Попробую немного описать:

Есть метод Retrieve(OID: Integer), который и вытаскивает все все данные.
Вызывать его можно хоть где и хоть когда. Но в данный момент он вызывается из
контекстного меню, и затем открывается форма.

самое интересное, можно сделать так:

var
dbo: TDBObject;
begin
dbo := TDBObject.Create('DBObject'); --Абстрактный класс
dbo.Retrieve(155); // Допустим это OID объекта класса документ DBOOrder

в таком случает откроется только его наименование и FolderOID, что и нужно для открытия контекстного меню. Объект в этом случае будет ReadOnly.

var
dbo: TDBObject;
begin
dbo := TDBObject.Create('DBObject');
try
dbo.Retrieve(155); // Допустим это OID объекта класса документ
dbo.AssignPopup(FPopupMenu);
finally
dbo.Free;
end;
end;

А форма открывается так:

procedure TDBOMenuItem.Click;
var
dbo := TDBObject;
begin
dbo := TDBObject.Create(DBClass);
dbo.Retrieve(OID);
dbo.Execute(Method); // Формы в системе зарегистрированы для всех public методов, таких как Просмотр, Редактировать, Создать новый, Переместить, Удалить и т.д. Для наследников можно добавлять новые и перекрывать имеющиеся методы. В итого Execute по классу и методу находит нужный класс формы и создает экземпляр. Затем передается себя в свойство DBObject: TDBObject и вызывает метод Init;
end;

Объект удаляется по закрытию формы.
Кроме того у объекта есть еще и private методы (Формы - это public). То есть:

DBObject['Name'] := 'П%';
DBObject.StoredProc('Find').Open;
if DBObject.StoredProc('Find').RecordCount = 1 then
DBObject.Retrieve(DBObject.StoredProc('Find')['OID']);
if DBObject.StoredProc('Find').RecordCount > 1 then
DBObject.Execute('Find'); //Открывается форма со списком найденных объектов
для выбора
//конкретного (Это уже public)
if DBObject.StoredProc('Find').RecordCount = 0 then
ShowMessage('По вашему запросы объекты не найдены');


Так что задача программиста просто писать новые классы на серваке и регистрировать новые формы, например новый класс (Создадим клиента, унаследованного от базового класса DBObject. У базового класса есть наименование, там мы будем хранить ФИО, но нам нужен еще адрес):

exec RegisterClass 'DBOClient', 'DBObject'

create table Clients
(
OID int not null,
Address varchar(255),
primary key clustered ( OID )
)
go

create procedure DBOClient_Open
@OID int
as
select * from Clients where OID = @OID
go

create procedure DBOClient_Create
@OID int,
@Address varchar(255)
as
insert Clients select @OID, @Address
go

create procedure DBOClient_Save
@OID int,
@Address varchar(255)
as
update Clients set Address = @Address where OID = @OID
go

create procedure DBOClient_Delete
@OID int
as
delete Clients where OID = @OID
go

Вот и все. Все остальное знает система. Нужно только новую форму зарегистрировать, т.к. в базовой у нас нет поля для адреса:

TfrmDBOClientEdit = class(TfrmDBObjectEdit)
edtAddress: TEdit;
public
procedure Init; override;
procedure Save; override;
end;

implementation

procedure TfrmDBOClientEdit.Init;
begin
inherited;
edtAddress.Text := DBObject['Address'];
end;

procedure TfrmDBOClientEdit.Save;
begin
inherited;
DBObject['Address'] := edtAddress.Text;
end;

регистрируем форму в юнит-файле RegClasses процедурой
RegisterClass('TfrmDBOClientEdit')

Теперь можно создавать объекты класса DBOClient, нажав кнопку создать и выбрав класс. Или редактировать, щелкнув правой кнопкой на объекте в эксплорере (Это спец форма для списка объектов)

guest

Постановка задачи - идея,

минимизировать разработку приложений и исключить ошибки.

план работ - конкретика,
прототип - описание,
полученные результаты - сравнение с существующими решениями

Существующие решения либо имеют ограничения по функционалу (1С)
либо низкую скорость работы (1С:)

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

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

задача программиста регистрировать новые сущности и новые формы, не заботясь о том как они вызываются, как к ним идет обращение. Этим занимается ядро

Guest Я так понял:

Объект:
Данные хранятся на сервере в базе (создаем руками),
Методы на сервере в ХП (создаем руками),

Создаем руками программный объект, который как-то связан с конкретными ХП.

далее при обращении к методам объекта вызываются ХП этого объекта.

Почти все правильно. На клиенте объект создавать не надо. Компонент по указанному классу полностью инкапсулирует в себе все данные сервера для заданного класса и идентификатора объекта.

Можно провести аналогию с компонентом, например, TADOTable. Указываешь TableName и все поля вытаскиваются. Мой компонент отличается от TADOTable также как Class отличается от record (struct) (добавилось наследование и методы)

Там наследования нет. Я уже давно все проштудировал

да ни того, ни другого толком нет. В Оракле например, если создать тип объект унаследованный, то создать таблицу по нему нельзя. Как это называется. Нахрена тогда наследование? Уж лучше на джаве тогда писать

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

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

Guest

Где живешь? Если в СПБ, то нет проблем

Сейчас не стану выкладывать. Допишу прикладное приложение, потом уже обкатанное ядро выложу на просмотр.

>1) Обращение к SQL серверу возвращает таблицу, значит для выборки всех
>полей объекта необходимо многократно обращаться к серверу.

Это если нужно многократно обращаться к серверу.

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

Моя система сделана на основе системы Онтарио. Я ее расширил, хотя и некоторые вещи переписал. Но существенного изменения нет, просто несколько автоматизировал разработку. Так вот

1. Количество объектов 500 000 записей
2. Количество прав объектов 2 000 000 записей
3. Количество записей в регистре проводок. 8 000 000
4. Таблиц всего 300 штук. Классов чуть больше 100. Процедур 3000 штук.
5. Количество пользователей ~ 50. Это на одной базе. А все баз 6 штук в разных регионах страны. Репликация по каналу интернет идет каждые 2 минуты.

Моя система в худшем случае понизит производительность на 20% из-за вытаскивания метаданных перед данными.

>А для создания сложных выборок по соединения нескольких таблиц такая
>схема абсолютно бесполезна.

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



Объекты на клиенте, представлены в виде прокси, т.е. только то что нужно для их идентификации. Это наименование, чтобы показывать в контролах, класс чтобы знать какие метаданные вытаскивать и идентификатор (понятно зачем).

>Привет, а как в вашей объектной системе реализованы вложенные объекты?
>(например: приходная накладная имеет ссылку на контрагента...)

Выше привел пример датасета (многострочная часть документа).
Чтобы открыть объект учета для просмотра, пишем:

var
dbo: TDBObject;
begin
dbo := TDBObject.Create(DBObject.DataSet['Things'].Field['ThingClass'].AsString);
dbo.Retrieve(DBObject.DataSet['Things'].Field['ThingOID'].AsInteger);
dbo.Execute('View');
end;

Набросал доку по своей системе. Кому интересно присылайте мыло, отвечу всем.

Знаю я Ультиму :-)
Ваши траблы я повторять не стал.
Привет Сергею Тарасову.
Я его систему развиваю. :-)

Оригинально и красиво решил проблему ссылочной целостности в своей системе.

Раньше на каждое поле, являющееся ссылкой на объект, нужно было писать процедуру типа

DBODoc_D_DBOState,

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

Сделал все через метаданные.
При регистрации класса в базе добавляется пользовательский тип основанный на int и имеющий название аналогичное классу, например DBODoc, теперь скрипт создания таблицы документов выглядит так

теперь при удалении объекта "Состояние документа" можно по метаданным найти все таблицы где есть поля этого класса и его наследников, проверить есть ли в этих полях ссылка на удаляемый объект и если есть, то по типу поля OID взять описание класса и ругнуться что в данном объекте есть ссылка на удаляемый объект и удаление отменяется.

Еще кое-что на тему на сайте

dbobjects.boom.ru

Выложил исходники на сайте

http://dbobjects.boom.ru

Ущербный какой-то этот Оракл. Я знал про объекты в нем, вернее про то как они там реализованы, поэтому и не стал его использовать. Лучше взять чистую реляционную СУБД и сделать объект на MIDDLE WARE.

Это большая ошибка, когда проектируют так что данными манипулирует AppServer. Он должен предоставлять интерфейс клиенту и через него манипулировать методами. А данные вытаскивать только в том случае, если их клиент запрашивает для отображения или изменения.

Люди, вы заложники своих стереотипов. Данными манипулировать должны только хранимые процедуры или SQL. А компонент на среднем звене должен представлять собой обертку вокруг разрозненного набора таблиц и процедур, чтобы превратить все это в целостную логическую единицу, представляющую собой сущность, которая может не только иметь данные и операции, но интерфейс для работы с ними.
Мой компонент управляет хранимыми процедурами (серверная часть) и формами (клиентская часть).
Сейчас я делаю подробное описание, как с помощью моего ядра сделать прикладное приложение. Это упрощенная клиентская база. Когда будет готово сообщу. Увидите как все просто.

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

Я перенес сайт на dbobjects.narod.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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