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

На сервере класс представлен таблицей и четырьмя процедурами
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

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