DataSnap: "взаимоотношения" RDM между собой

← →
d_oleg © (2007-07-13 09:27) [0]

Подскажие пожалуйста, чего-то я видимо недопонимаю...

Есть проект 3х звенка на DataSnap. Сервер представляет собой набор объектов TRemoteDataModule, клиент коннектится к главному, с помощью TSharedConnection имеет доступ к остальным remotedataмодулям. Тут все вполне стандартно и понятно TSharedConnection обращается к свойству главного модуля, оный модуль отдает интерфейс созданного объекта.

Так вот, про взаимодействие объектов внутри сервера - в главном модуле лежит компонент-подключение к БД, в остальных - dataset"ы доступа к данным. В дизайн-тайме в cвойства Database DataSet"ов очень замечательно проставляется компонент, находящийся в главном модуле.
Т.е.

TMainRDM = class(TRemoteDataModule, IMainRDM) Database: TpFIBDatabase; ...... end; MainRDM: IMainRDM TChildRDM = class(TRemoteDataModule, IChildRDM) Dataset: TpFIBDataSet; ....... end; DFM: object tele_data: TpFIBDataSet Database = MainRDM.Database end;

Внимание вопрос: как это происходит? Ведь MainRDM - это интерфейс, как он может фигурировать в DFM? К тому же нет у него свойства Database.

Спрашиваю для того, чтобы понять, как можно подобное присвоение сделать в коде в run-time.

← →
Сергей М. © (2007-07-13 09:58) [1]

> MainRDM: IMainRDM

Эту переменную ты создал "ручками" ?

Что-то не припоминаю я, чтобы эксперт создавал в RDM-юните глоб.переменную интерфейсного типа.

← →
d_oleg © (2007-07-13 11:08) [2]

> Эту переменную ты создал "ручками" ?

нет, автоматом в _TLB файле.

← →
Сергей М. © (2007-07-13 11:23) [3]

> d_oleg © (13.07.07 11:08) [2]
> нет, автоматом в _TLB файле.

Хм..

Только что в Д7 я создал средствами эксперта "чистый" RDM, при этом эксперт кроме юнита с RDM-классом создал соответствующий TLB-юнит.

В упор не вижу ни там ни там никаких переменных интерфейсного типа.

Да и какое непосредственное отношение TLB-юнит имеет к DFM ? Imho, никакого.

Так что, думается, эта интерфейсная переменная, фигурирующая у тебя - чистая отсебячина)

← →
d_oleg © (2007-07-13 11:49) [4]

> Хм..

Так, стормозил... :(

Никакая это не переменная, MainRDM = IMainRDM, т.е. описание Co-класса

> Да и какое непосредственное отношение TLB-юнит имеет к DFM ?
Согласен, никакого. Просто не пойму, на что ссылается DFM строчкой
> MainRDM.Database

← →
Сергей М. © (2007-07-13 12:13) [5]

> не пойму, на что ссылается DFM строчкой
> MainRDM.Database

Как это на что ? Разумеется на объект-компонент с именем (т.е. св-вом Name) "MainRDM".

B св-во Database у этого объекта имеется, потому как оно у тебя published по умолчанию

← →
Сергей М. © (2007-07-13 12:16) [6]

> св-во Database у этого объекта имеется

Точнее не св-во, а поле соотв.типа.
Коль ты не указал спецификатор области видимости для этого идентификатора, он автоматически становится published с соответствующими последствиями, кои ты и наблюдаешь.

← →
d_oleg © (2007-07-13 13:50) [7]

> Как это на что ? Разумеется на объект-компонент с именем
> (т.е. св-вом Name) "MainRDM".

Так откуда он берется-то? Вот в чем вопрос. Ведь на этапе проектирования мы имеем всего лишь тип TMainRDM, но ни одного одъекта этого типа.

← →
d_oleg © (2007-07-13 13:51) [8]

> B св-во Database у этого объекта имеется, потому как оно
> у тебя published по умолчанию
> ....

Тут-то все понятно.

← →
Сергей М. © (2007-07-13 14:11) [9]

> d_oleg © (13.07.07 13:50) [7]

> ни одного одъекта этого типа

Как это "ни одного" ?

А что, по-твоему, есть то на что ты кинул тот самый компонент Database ?

← →
d_oleg © (2007-07-13 15:26) [10]

> А что, по-твоему, есть то на что ты кинул тот самый компонент
> Database ?

И где "оно" описано?

← →
ага (2007-07-13 19:17) [11]

2 d_oleg © (13.07.07 15:26) [10]
> А что, по-твоему, есть то на что ты кинул тот самый компонент
> Database ?

И где "оно" описано?

Ты че, прикалывашься? В дфмке естесно того модуля где у тя TMainRDM описано. Ну ет для дизайнера. А для раантайма у тя сам модуль есть. Ну ты сослася на него в юзес - усе, тип то компилеру известен, чеб ему не видеть?

← →
d_oleg © (2007-07-14 15:34) [12]

Тип виден, но не виден непосредственно объект типа, не описан он. Еще раз: не описан ни один объект данного типа. Что мне мешает создать таких объектов с десяток - какой из них будет использован?

← →
Сергей М. © (2007-07-16 09:32) [13]

> d_oleg © (14.07.07 15:34) [12]

Ты вообще справку на тему "Using multiple remote data modules" читал ?

← →
d_oleg © (2007-07-16 11:57) [14]

> Ты вообще справку на тему "Using multiple remote data modules"
> читал ?

И что там по теме, кроме общих слов? Единственное похожее:

> You may also want to extend the interface for each child
> data module, exposing the parent data module"s interface,
> or the interfaces of the other child data modules. This
> lets the various data modules in your application server
> communicate more freely with each other.
>

Но во-первых тут говорится про You may also want..., а я говорю про ситуацию "по умолчанию", безо всяких дополинтельных телодвижений со стороны разработчика, а во-вторых, тут ничего не написано на тему, как это сделать. Банально добавить проперть и установить ее в момент создания? Да, это можно, но повторюсь: по умолчанию нет никаких дополнительных свойств, мне интересен именно этот подход.

← →
Сергей М. © (2007-07-16 12:09) [15]

> мне интересен именно этот подход

В твоей задаче это изначально неверный подход.

> безо всяких дополинтельных телодвижений со стороны разработчика

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

> Это подход батонокидателя, а не "разработчика"

Подход разработчика - это понимать, как работает то, что ты пишешь. А не пихать везде код made by я любимый. Если есть стандартный путь взаимодействия - лучше воспользоваться им, а не изобретать каждый раз велосипед, не так ли?

> d_oleg © (16.07.07 13:05) [16]
>
>

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

Только что я провел "чистый" эксперимент:

1. Средствами эксперта создал заготовку проекта AX-библиотеки
2. Средствами эксперта создал в составе проекта пару RDM
3. На один RDM бросил ADOConnection, на другой ADOTable

В Инспекторе объектов открываю список для выбора значения свойства ADOTable.Connection - он девственено чист ! Что собссно и ожидалось)

> Сергей М.

в uses-то написал модуль с другим RDM?

> в uses-то написал модуль с другим RDM?

Нет, не написал.

Ну хорошо, я указал оной, вижу в списке имя.

И что ?

Где, спрашивается, в ран-тайм будет осуществляться поиск этого самого компонента с именем "MainRDM", если его Owner = nil ?

Ты просто получишь исключение - и всех делов.

Нет, не так вопрос стоит. Когда я выбираю в cild компонент из main, получается, что я обращаюсь непонять к чему - не описано такого объекта (переменной) MainRDM, есть тип MainRDM = IMainRDM, описанный в _TLB.pas
К чему же я обращаюсь в таком случае? Где мне искать этот объект в run-time?

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

> К чему же я обращаюсь в таком случае?

Ты обращаешься к компоненту с именем "MainRDM", существующему в дизайн-тайм.

Будет ли компонент с этим именем существовать в ран-тайм на момент обращения к нему - таких предположений Инспектор не делает за ненадобностью, полагаясь очевидно на полное твое понимание как разработчика, а не батонокидателя.

> потом к этому объекту можно обратиться через переменную

При загрузке св-в компонента из DFM ни о каких "переменных" речи не идет - тот самый "MainRDM" расценивается "загрузчиком" как имя потенциально существующего на этот момент компонента.

> Ты обращаешься к компоненту с именем "MainRDM"

все, спасибо, разобрался.

DataSnap: "взаимоотношения" RDM между собой Найти похожие ветки