передача соединения с БД между разными DLL

[londinium]

Здравствуйте, Господа!

Обдумываю сейчас структуру будущей программы. Преамбула такова - клиент будет писаться на C++Builder для FireBird с помощью компонентов IBX. Структура БД более-менее готова, возможны, конечно, мелкие доработки. Поскольку в БД возможно добавление/удаление полей, то возникла идея вынести работу с сервером на уровень хранимых процедур, а клиентские формы добавления/редактирования/удаления/поиска по фильтру положить в DLL, чтобы при изменении структуры БД менять не все приложение, а только одну DLL.
В связи с этим вопрос, как организовать работу такой DLL - чтобы она цеплялась к базе и работала. Класть в каждую DLL DataModule и соединяться с базой или каким-то образом можно обойтись одним подключением к базе (например, передавая дескриптор соединения между DLL. Как его в таком случае правильно передать?)? Как правильно поступить в таком случае?


С уважением, Londinium

[hvlad]

Package

[kdv]

по-моему идея паршивая. хотя все зависит от реализации.
Впрочем, чем тогда будет заниматься приложение - только грузить dll? тогда какой смысл?
какая разница, что менять - одну dll или один exe? где уверенность, что пользователь сможет корректно заменять dll? и т.д.

[londinium]

Впрочем, чем тогда будет заниматься приложение - только грузить dll? тогда какой смысл?

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

[kdv]

Разве такая схема более кривая?

конечно. допустим, один раз добавил столбец в справочниках. изменение одной длл проканает. А потом изменил два столбца в двух разных длл.
Я пока не могу понять выгоды от изменения длл и всего этого гемора с пэкэджами вместо изменения одного exe. Аргументов нормальных не вижу.
Рекомендую все-таки продумать не "как у меня все будет красиво и зашибись", а "как я буду этот кошмар обновлять у клиентов, и какие проблемы могут вылезти". Побольше пессимизма - ибо большинство кривого софта сделано с благими намерениями о "красиво".

p.s. за исключением, может быть, отчетов. которые лучше вообще хранить как отдельные файлы. большинство отчетных компонент такое позволяют.
p.p.s. вот, например, ресурсы для разных языков в dll - это нормально. Еще - разные запросы для разных СУБД. Примерно так. А пока идея выглядит как "я бизнес-логику порубаю топором на части и положу в разные места, и будет кайф". В чем кайф, если туфли лежат в подвале, рубашка в комнате, а костюм на чердаке?

[WildSery]

"как я буду этот кошмар обновлять у клиентов, и какие проблемы могут вылезти".

Полностью поддерживаю. Особенно стоит подумать о работе с БД нескольких DLL _разных_ версий, по какой-либо причине не вызывающих конфликта _сразу_.

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

Вот тут не соглашусь. Отчёты лучше хранить в БЛОБах в самой БД. Большинство отчётных компонент такое позволяют

[Antoxa]

А как засунить шаблон отчета fr_4 в блоб???

[kdv]

А как засунить шаблон отчета fr_4 в блоб???

а как вообще засунуть в блоб что либо? www.ibase.ru/ibfaq.htm

[avenger]

Я передаю дескриптор соединения в dll с помощью следующей структуры

Код: Выделить всё

type
  PDBExportHandle = ^TDBExportHandle;
  TDBExportHandle = packed record
    Handle: TISC_DB_HANDLE;
    LibraryName: PChar;
    SQLDialect: Integer;
    CharSet: PChar;
  end;

А потом в dll так:

Код: Выделить всё

        dbMain.LibraryName           := ADBExportHandle^.LibraryName;
        dbMain.ConnectParams.CharSet := ADBExportHandle^.CharSet;
        dbMain.SQLDialect            := ADBExportHandle^.SQLDialect;
        dbMain.Handle                := ADBExportHandle^.Handle;