Как правильно наследоваться от TDataModule?

← →
Рыбба (2009-01-14 10:30) [0]

Здраствуйте. В Делфи я новичок, так что сильно не пинайте.
Решил сделать маленький проектик с базами с использованием наследования. Т.е. сделал какой-то каркас, а затем в проекте наследуешься от него. Сделал классы форм - все нормально наследуется и используется.
Но хочу так же сделать и с TDataModule. Сделал общий датамодуль (TMyDM), а как наследоваться от него? Ведь в классах формы есть ссылки на TMyDM (датасурсы, гриды, вызовы процедур и прочее)?
Если сделать новый датамодуль (TDM = class(TMyDM)) то придется вручную поменять ссылки на TDM, тогда смысл?

Подскажите как правильно. Спасибо

← →
Кит (2009-01-14 10:50) [1]

File > New > Other...
[Тут вкладка с именем твоего проекта] > Ищешь твой датамодуль MyDM выбираешь внизу Inherit > Ok

Усё.

← →
Рыбба (2009-01-14 12:00) [2]

Прочитайте внимательней

← →
MsGuns © (2009-01-14 12:04) [3]

Если вся (или почти вся) логика обмена с БД инкапсулируется в датамодуль, зачем делать от него наследника ?
Мне почему-то кажется, что Вам надо реализовать несколько форм, работающих с разными экземплярами одних и тех же объектов связи с БД (как пример, два или более экземпляра одной и той же формы просмотра содержимого одного и того же запроса, но с разными параметрами). Если так, то для каждой формы не нужно создавать датамодуль по "образу и подобию" основого. Надо все объекты (датасеты обычно) располагать в самих формах, а вот некотрый функционал (например, обработка событий датасетов, обработка ошибок, установление соединения с БД и т.д.) реализовать в основном ДМ. Тогда при достаточной автономности интерфейсных модулей (форм, фрэймов и т.д.) Вы получите компактность и унифицированность кода.

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

← →
MsGuns © (2009-01-14 12:13) [4]

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

ИМХО, более одного "базаданного" датамодуля имеет делать только если у Вас, например, более одной БД одновременно либо есть некий кусок (например, объявления классов в объектной БД), стоящий вне физических БД, как бы над ними, но актуальный для физических БД. Либо Вы хотите часть деклараций и реализации вынести из проекта для дальнейшего использования (например, в репозиторий) в других разработках.

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

← →
Ega23 © (2009-01-14 12:15) [5]

type TMySuperPuperMegaForm = class (TForm) private procedure SetDataModule(Value : TMySuperMegaDataModule); public property MySuperMegaDataModule : TMySuperMegaDataModule read FMySuperMegaDataModule write SetDataModule; end; procedure TMySuperPuperMegaForm.SetDataModule(Value : TMySuperMegaDataModule); begin FMySuperMegaDataModule := Value; if Value=nil then Exit; Подключаем все контролы и всё остальное... .... end;

← →
Рыбба (2009-01-14 12:42) [6]

[3], [4]
Спасибо за ответ.
Расскажу немного.
На датамодуле-предке (TMyDM) находятся общие процедуры работы с БД, а также расположены компоненты подключения к серверу БД, несколько датасетов для операций с базой (например, для разовых выполнений каких-то запросов) и некоторые невизуальные компоненты. Ну, например, ImageList (который в себе хранит картинки, например, для разных состояний записи - проведен, не проведен, удален и прочее). Или, возможно, набор стилей для грида DevExpress. Соотственно, в некоторых формах есть ссылки, допустим на ImageList. После наследования эти ссылки должны вести не на предка, а на потомка. Во-вторых, в коде есть явное указание датамодуля, например в коде:
with MyDM.DataSet do begin ... end;
Опять же после наследования он будет вести не туда. Но датамодуль один, на него вынесены лишь некоторые датасеты (например для констант или редко неизменяемых справочников). Остальные датасеты находятся на соответствующих формах (например, справочник Номенклатуры на форме Номенклатура и т.д.)
Можно попытаться все изменяемое вынести в другой юнит (не обязательно датамодуль), принадлежащий конкретному проекту. Получится ли и не возникнет каких-либо проблем - я пока не могу точно утверждать.

[5] Спасибо за пример. Попробую вечером. А визуально я могу сослаться на property MySuperMegaDataModule в дизайнере форм?
Еще недостаток этого подхода по-моему: форма должна быть подключена практически везде для видимости. Всем видимый датамодуль как-то привычней... Но это уже, наверное, дело вкуса

← →
Медвежонок Пятачок © (2009-01-14 12:42) [7]

Ведь в классах формы есть ссылки на TMyDM

ну и пусть будут ссылки.

← →
Медвежонок Пятачок © (2009-01-14 12:47) [8]

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

С наследованием это никак не связано.
У меня например базовый Dm и сто его наследников для разных библиотек доступа и разных субд.
Но в приложении единственный экземпляр dm

← →
Ega23 © (2009-01-14 12:50) [9]

> А визуально я могу сослаться на property MySuperMegaDataModule
> в дизайнере форм?

Ну если наприльником заточить - то пуркуа бы и не па. А смысл?

← →
Медвежонок Пятачок © (2009-01-14 12:52) [10]

with MyDM.DataSet do begin ... end;

with GetMyDataModuleMethod.DataSet do begin ... end;

← →
Рыбба (2009-01-14 13:02) [11]

[9] При дизайне проекта в среде. Или всю привязку делать в рантайме?
[10] А при визуальном проектировании?

← →
Ega23 © (2009-01-14 13:30) [12]

> [9] При дизайне проекта в среде. Или всю привязку делать
> в рантайме?
> [10] А при визуальном проектировании?

Я в рантайме делаю. Дизайн-тайм развращает.... :)

Но можно сделать и для дизайн-тайм.

← →
MsGuns © (2009-01-14 14:04) [13]

>Медвежонок Пятачок © (14.01.09 12:47) [8]
>С наследованием это никак не связано.

А я не нсоветовал наследовать

>У меня например базовый Dm и сто его наследников для разных библиотек доступа и разных субд. Но в приложении единственный экземпляр dm

Бога ради. Но я предпочитаю ОБЩИЙ код делать универсальным и выносить его вообще из проектов в библиотеку. Так просто удобнее ИМХО. И не нужно использовать наследование ИМХО оно здесь неуместно.

>Рыбба (14.01.09 12:42) [6]

Ваш пример очень вписывается в "библиотечную схему". Все процедуры и функции библиотеки получают необходимые объекты в виде ссылок параметирами, сам ни к кому не обращаясь напрямую. И их можно (и нужно !) использовать в других "родственных" проектах.
Если задача (не проект, а проектируемая система в целом) достаточно сложная, то общие алгоритмы, классы и т.д. предпочтительнее разбить на несколько юнитов. Опять же как в делфи :)

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

← →
Медвежонок Пятачок © (2009-01-14 14:13) [14]

Бога ради. Но я предпочитаю ОБЩИЙ код делать универсальным и выносить его вообще из проектов в библиотеку. Так просто удобнее ИМХО. И не нужно использовать наследование ИМХО оно здесь неуместно.

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

так что "общий код" только в базовом классе.

← →
MsGuns © (2009-01-14 14:22) [15]

>Базовый модуль содержит реализацию всей логики бизнес процессов.

Аналогично для библиотечной технологии

>Но при этом ничего не знает ни о компонентах доступа, ни о платформе.

Кхе-кхе, это как ?

>Наследники наоборот, понятия не имеют и не содержат никаких алгоритмов.
>Но устанавливать соединение на конкретных компонентах доступа к конкретному серверу.

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

>так что "общий код" только в базовом классе.

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

У меня, кстати, библиотечным образом реализовано куча форм, всякие поиски, фильтры, диалоги и т.д. Так что в проекте не надо никаких форм, датамодулей и т.д. которые пусть они хоть вообще не содержат кода, но все же "тянут" на себя и ресурсы, и время, и утяжеляют проект, добавляя в него доп.файлы (вот не люблю я когда в рабочей папке сотни файлов, и всё !)

Хотя, кончно, кому поп, кому попадья :)

← →
Медвежонок Пятачок © (2009-01-14 14:26) [16]

Кхе-кхе, это как ?

Обыкновенно. Вся работа идет на уровне TDataSet.

← →
MsGuns © (2009-01-14 14:29) [17]

Ты ж сказал "ничего не зная о компонентах" и, тем более "платформе" :)

"Как понимать тебя, Саид ?" (с)

← →
Ega23 © (2009-01-14 14:37) [18]

> Ты ж сказал "ничего не зная о компонентах" и, тем более
> "платформе" :)

Всё потомок TDataSet.

← →
Медвежонок Пятачок © (2009-01-14 14:43) [19]

Базовый модуль данных ничего не знает о компонетах (bde,ado,fibs,odac etc)
И про сервер ничего не знает. Это может быть любой сервер или вообще файлы dbase/paradox

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

Когда мне нужно зарелизить версию на новом сервере с новыми компонентами доступа, я просто создаю потомка, добавляю в него конннекшен, пару дататсетов, и переопределяю порядка десятка методов.

В переопределенных методах никакой бизнес логики нет, голая техника типа такого

function CreateSelectSQLComponent(const ASQLText : string; var AComponent : TComponent; AOpen : boolean; const AEditTableName,AkeyFields,AGeneratorName : string) : boolean; overload; override;

итого: чтобы собрать новую версию на совершенно другом движке и компонентах уходит час - полтора.

← →
Jeer © (2009-01-14 15:04) [20]

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

← →
Ega23 © (2009-01-14 15:19) [21]

> Мне вообще ничего практически не надо делать (изменять приложение),
> чтобы работать с большинством SQL-серверов :))
> Более того, обеспечена одновременно работа с многими SQL-
> серверами одним приложением. :))

У слона всё равно длиннее.
И толще.

← →
Рыбба (2009-01-14 15:47) [22]

Почитал. Хочется сначала попробовать метод [5]. Однако не получается увидеть свойство MySuperMegaDataModule в дизайнере объектов. Не подскажите решение / ссылочку. Спасибо

← →
Игорь Шевченко © (2009-01-14 16:22) [23]

Если рассматривать приложение в рамках парадигмы Model-View-Controller, то базовый datamodule вполне может быть абстрактной моделью, а его наследники - конкретными моделями.
Не вижу ничего криминального в создании наследников datamodule, единственное что предложу автору - это не ссылаться нигде по имени на переменную конкретного экземпляра datamodule типа MyDm.MyDataSet

← →
Рыбба (2009-01-14 16:39) [24]

[23] Допустим в коде я могу убрать ссылки (и то думаю будет непривычно), но как быть с ссылками в дизайн-тайме? Думается, что все-таки писать привязки в рантайме слишком громоздко

← →
Ганя (2009-01-14 16:43) [25]

> Думается, что все-таки писать привязки в рантайме слишком
> громоздко

Советую писать их именно в ран тайм.
Дело в том, что в силу некоторых косяков среды (а именно, периодического обниливания ссылок на внешние модули\формы в дизайнере), удобство работы "мышкой" полностью портится необходимостью ведения борьбы с этими "фичами"

← →
Игорь Шевченко © (2009-01-14 17:01) [26]

> но как быть с ссылками в дизайн-тайме?

какие ссылки в design-time имеются в виду ?

← →
MsGuns © (2009-01-14 17:20) [27]

>Ega23 © (14.01.09 14:37) [18]
>Всё потомок TDataSet.

Кхе-кхе два раза, но, извиняюсь, кто у пресловутого датасета в отцах ходит, ась ?

>Jeer © (14.01.09 15:04) [20]
>Более того, обеспечена одновременно работа с многими SQL-серверами одним приложением. :))

Осталось только выяснить крохотный вопросец - а что, собсна, умеет делать это самое приложение ? :)

>Медвежонок Пятачок © (14.01.09 14:43) [19]
>Базовый модуль данных ничего не знает о компонетах (bde,ado,fibs,odac etc)
>И про сервер ничего не знает. Это может быть любой сервер или вообще файлы dbase/paradox
>Но он все знает о том, как должны делаться инсерты/апдейты/делеты и прочее. Содержит всю >бизнес логику и все алгоритмы.

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

>Когда мне нужно зарелизить версию на новом сервере с новыми компонентами доступа, я просто >создаю потомка, добавляю в него конннекшен, пару дататсетов, и переопределяю порядка >десятка методов.

Чем эта парадигма предпочтительнее следующей:
"Когда я реализую новый сервер, то в первую очередь использую функционал библиотеки, а если его недостаточно, то пишу свой, иногда перенося его в те же библиотеки, расширяя их функции и уменьшая таким образом трудоемкость проектирования в перспектие ?"

← →
Jeer © (2009-01-14 17:27) [28]

> MsGuns © (14.01.09 17:20) [27]
> >Jeer © (14.01.09 15:04) [20]
> >Более того, обеспечена одновременно работа с многими SQL-
> серверами одним приложением. :))
>
> Осталось только выяснить крохотный вопросец - а что, собсна,
> умеет делать это самое приложение ? :)
>

OLAP

ну ты эта.. реально крут :)

← →
Рыбба (2009-01-14 17:44) [30]

> какие ссылки в design-time имеются в виду ?

Допустим привязка TADODataSet.Connection = TADOConnection в инспекторе свойств

> Дело в том, что в силу некоторых косяков среды (а именно,
> периодического обниливания ссылок на внешние модули\формы
> в дизайнере), удобство работы "мышкой" полностью портится
> необходимостью ведения борьбы с этими "фичами"

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

> Допустим привязка TADODataSet.Connection = TADOConnection
> в инспекторе свойств

В моем (например) случае connection хранится в своем datamodule не входящем в иерархию (connection-ов обычно меньше, чем DataSet-ов), соответственно, ссылка в design-time тоже наследуется.
Если очень боязно за то, что пропадет, можно на событии Loaded предка в иерархии присвоить это свойство в run-time, тогда оно автоматически распространится на наследников.

>Рыбба (14.01.09 17:44) [30]
>> Дело в том, что в силу некоторых косяков среды (а именно,
>> периодического обниливания ссылок на внешние модули\формы
>> в дизайнере), удобство работы "мышкой" полностью портится
>> необходимостью ведения борьбы с этими "фичами"

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

Если это не секрет, о каких "фичах" речь ? Вот уже сколько лет дружу с делфей, но не видел и даже не слышал.

ЗЫ. В целом ветка напоминает диспут о том, как монтировкой ковыряться в зубах. Как говорится, попутного ветра !

Вот уже сколько лет дружу с делфей, но не видел и даже не слышал.

Просто у всех проекты разной степени сложности.
Фича пропадания паблишед свойств-ссылок на компоненты известна очень давно.

> Если это не секрет, о каких "фичах" речь ? Вот уже сколько
> лет дружу с делфей, но не видел и даже не слышал.

А такая. Приходишь утром на работу. Запускаешь Delphi. Открываешь вчерашний проект (вчера перед выходом всё работало). Бах - а во всех ДБгридах пропали ссылки на датасорсы. И вообще, во всех ДБ-контролах пропали ссылки на датасорсы.
И если по какой-то причине не залил в CVS, то приходит .ОПА.

>Бах - а во всех ДБгридах пропали ссылки на датасорсы. И вообще, во всех ДБ-контролах >пропали ссылки на датасорсы.

Ух ты ! А как сделать такой веселый "Бах" ?
:)

> Ух ты ! А как сделать такой веселый "Бах" ?

А пёс его знает. Я серьёзно. Несколько раз натыкался. Хорошо ещё, если сразу заметил и нормальную версию из CVS выгрузил. А то бывает, что уже изменений навносил кучу.

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

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

Еще есть главный датамодуль, который содержит в себе соединения к разным БД, умеет работать со всякими сервисами типа нотификаций и конфигурирования и т.д.

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

> У нас в проектах не принято выносить объекты данных в датамодули.
> Всё живет непосредственно на фреймах, благо они, как правило,
> небольшие.

Угу, я "опытным путём" к такой же идеологии пришёл.

аналогично.
все "визуализируемые" датасеты лежат там же, где и датааваре контролы.

Ega23 © (15.01.09 12:30) [38]
Медвежонок Пятачок © (15.01.09 12:46) [39]

А если к конкретному датасету потребуется обратиться из другой (возможно невизуальной) части проекта ?
(причем, к уже открытому)

Как правильно наследоваться от TDataModule? Найти похожие ветки