Вынос модуля данных в DLL

← →
AlekVolsk (2011-05-13 16:54) [0]

Есть желание воспроизвести примерно следующее.
В одной dll - модуль данных с доступам к различным БД (одного формата), используемых одновременно. Во всех остальных dll - различные самостоятельные независимые друг от друга модули программы, каждый из которых содержит от 20 до 100 форм (не считая диалогов и прочего функционала, используемого сразу в нескольких модулях, вынесенного в отдельную dll), где имеются только TDataSource, ссылающиеся на TDataSet в dll с модулем данных.
По сути сейчас в каждой dll - свой модуль данных, задача - вывести его в отдельную dll.
Пока даже браться боюсь, хотя мысль мусолю ухе более года, да только не знаю с какой стороны начать. Жажду мыслей.

← →
OW © (2011-05-13 17:18) [1]

> Жажду мыслей.

мысль один: думать о bpl, а не dll. Ни разу у нас ничего хорошего не получилось с dll.

мысль один и еще один: не думать о разделении вообще. Два раза у нас получилось хуже, нежели было все а одном exe.

исключение - really Профи,
но у них таких вопросов возникнуть не должно :)

← →
sniknik © (2011-05-13 18:47) [2]

> исключение - really Профи,
у них и мыслей таких нет. что за идиотизм разделять 1 логику общения с базой на 2 (программа -> dll), без всяких на то оснований... ну понимаю была бы нужда какая, можно было бы потерпеть неудобства/усложнение, но вот просто так, "от нечего делать?".

трехзвенку сделай, хотя и она если без оснований глупость.

← →
_Юрий (2011-05-13 19:12) [3]

> да только не знаю с какой стороны начать

Начни со стороны смены технологии в сторону веба

← →
Anatoly Podgoretsky © (2011-05-13 21:59) [4]

> AlekVolsk (13.05.2011 16:54:00) [0]

Начни с изучения BPL

← →
AlekVolsk (2011-05-14 00:15) [5]

> исключение - really Профи, но у них таких вопросов возникнуть не должно

Однако возникли. Проект пишется и развивается уже 8 лет. Поначалу это был один exe"шник, затем он разросся, стал собирать с runtime-пакетами. В определенный момент возникла необходимость поддерживать несколько параллельных версий для различных контор, решил делать универсальный один на всех. Разбил на dll"ки, в каждой отдельный модуль (общий функционаз, вынесенный отдельно, не всчет), в exe выводится только авторизация и список модулей, доступных пользователю сог-но выставленных админом прав. Модули как самостоятельные, так и зависимые от других. В каких-то конторах нужны одни модули, в каких-то - другие, везде есть общие модули.
В среднем в каждой конторе работают одновременно 150-200 пользователей, у всех различные права доступа. Кому-то определенные модули просто не нужны, а каждый весит от 1,5 метров, общее кол-во модулей - 34. В каждом модуле свой TDataModule, 70% содержимого которого повторяется практически везде. Эти 70% повторяющегося содержимого - примерно половина от всего объема модуля.
Была идея создать что-то аналогичное 1С: скриптовый движок и набор скриптов, определяющщий логику работы каждого модуля, в т.ч. интерфесное построение. Безопасники отмели как класс - не положено-сс...
Трехзвенка не очень актуальна - кроме админов, все работают через rdp, и прога и база буквально в одной папке.

> Начни со стороны смены технологии в сторону веба

Не сталкивался ни разу, пока для меня - темный лес

← →
sniknik © (2011-05-14 01:20) [6]

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

> а каждый весит от 1,5 метров, общее кол-во модулей - 34
а слить все в 1 exe то и 3-х метров не будет... т.к.
> В каждом модуле свой TDataModule ...

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

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

← →
_Юрий (2011-05-14 10:00) [7]

> Не сталкивался ни разу, пока для меня - темный лес

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

> Кому-то определенные модули просто не нужны, а каждый весит
> от 1,5 метров, общее кол-во модулей - 34.

По современным условиям, это копейки.Не стоит обращать внимания.

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

На мой взгяд, правильный ответ - монолитный exe с правильной внутренней архитектурой (те же логические слои, но в коде). Ну будет он весить 30 метров, и ничего страшного.

← →
Дмитрий Белькевич (2011-05-14 13:11) [8]

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

← →
AlekVolsk (2011-05-14 17:59) [9]

> нужной частью пользуются, не нужную игнорируют

если бы все было так просто, но любопытство не порок (и далеко не для всех любопытство - хобби), а непреодольмое желание подставы из вредности

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

и при этом у всех full-inet, даже прикси нет. Абсурд, но не от меня зависящий... Правда, все string-поля внутри базы utf-16 + заксорены, а суммы помножены на определенную константу.

> я думал, проект только начинается. Начинать такое писать нуля на делфи сейчас было бы неосмотрительно.

возможно, но другого ничего я и не знаю, без офф. образования, проект поднимаю в одиночку

> Ну будет он весить 30 метров, и ничего страшного

Весит 93 метра, включая bpl. Страшное в том, что железо на серваках - обычные машины под P4 или CoreDuo с 2Gb памяти, под W2K3, через rdp 150 зверей - слабовато будет...

Я понимаю, что предложенный в заголовке вариант - тот еще гемор, и врят ли я буду его когда-либо реализовывать, просто желал "услышать" мнение и, возможно, мысли по поводу конкретной реализации (а вдруг кто-нить да заморочился?)

← →
sniknik © (2011-05-14 18:47) [10]

> Весит 93 метра, включая bpl.
а "моно" exe будет "весить" не более 10.

> Страшное в том, что железо на серваках - обычные машины под P4 или CoreDuo с 2Gb памяти, под W2K3, через rdp 150 зверей - слабовато будет...
ну вот, а зачем за подобную организацию работы "цепляешься"? зачем отверг нормальный клиент-сервер? ведь какое послабление нагрузки будет! на порядки.

> мысли по поводу конкретной реализации
мысль такая - забудь об этом поскорее... почитай про нормальные субд, и программирование.

не, если ты программист-мазохист, то вперед! но для начала уволься, и страдай-наслаждайся в одиночку, не зачем пользователей к этому же принуждать.

← →
AlekVolsk (2011-05-14 20:05) [11]

> а "моно" exe будет "весить" не более 10.

29,4

> зачем отверг нормальный клиент-сервер?

а его никто и не отвергал, просто и клиент, и сервер выполняются на одной машине, на серваке, ибо клиентские машины - максимум P4 или Sempron до 1,5GHz и до 512 метров памяти, встречаются и P2 под Win95... грузить каждый раз по сети сотню метров - издевательство, поетому и разбивал на dll

> нормальные субд

а чем Firebird 2.5 не устраивает?

> для начала уволься

да я бы рад бы, да семью кормить... ;))))))))
все бы ничего, но в маленьком провинциальном городке на окраине Руси не так много программеров, поэтому и приходится работать на 7 контор, которые еще и отпускать не желают (да и идти от них некуда).

← →
Palladin © (2011-05-14 20:20) [12]

а сколько человек это чудо делают 8 лет?

← →
Inovet © (2011-05-14 20:45) [13]

> [11] AlekVolsk (14.05.11 20:05)
> грузить каждый раз по сети сотню метров - издевательство,
> поетому и разбивал на dll

Что-то я не понял, чего 100 метров каждый раз, и какой каждый раз, грузить.

← →
sniknik © (2011-05-14 21:44) [14]

> Что-то я не понял, чего 100 метров каждый раз, и какой каждый раз, грузить.
у него программа лежит на сервере, рядом с базой/работает с базой "из директории" похоже, как файл сервер. ну, и если так, то понятно откуда/зачем взялся rdp, чтобы не грузить сеть загрузкой программы с сервера при старте/базы по пути при открытии.

а то, что "издевательство" это как раз то, что он делает... он не думает/не знает. т.к. самоучка(это он говорил), и не хочет изучать/читать про нормальную работу с субд (это догадки).

← →
Inovet © (2011-05-14 22:24) [15]

> [14] sniknik © (14.05.11 21:44)
> у него программа лежит на сервере, рядом с базой/работает
> с базой "из директории" похоже, как файл сервер

Так про ФБ2.5 говорилось... Странно это всё.

← →
Andy BitOff © (2011-05-14 22:48) [16]

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

← →
sniknik © (2011-05-14 23:43) [17]

> Так про ФБ2.5 говорилось...
ну так, он может работать без сервера, вернее без его установки, обращаясь из своей dll (содержащей весь сервер) прямо к файлу базы данных.
(и да подобное вроде называется персональным режимом, т.е. поддерживает только 1 коннект, поэтому не удивлюсь если ему пришлось делать кучу копий dll-ек, под каждый коннект свою. хотя..., это скорее всего бред моего воображения, уж очень оно разыгралось на основании странных желаний, и описаний, данных в этой ветке)

← →
Palladin © (2011-05-14 23:47) [18]

> Andy BitOff © (14.05.11 22:48) [16]

oO, мнэ страшна

← →
Andy BitOff © (2011-05-14 23:54) [19]

> Palladin © (14.05.11 23:47) [18]
> oO, мнэ страшна

=) Не-е-е, это один проект, который ПРИХОДИТСЯ поддерживать и он на мне. В остальном разработка нового ;) Так же разработка новой версии этого продукта, но пока от старой не отказаться.

← →
AlekVolsk (2011-05-15 00:31) [20]

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

> На кол таких, которые учиться не хотят.

хорошо вам там, в столицах, а у нас на деревне и 2 пту - и те одних дебилов выпускают, которые базы с прогами в одной папке держат. заочно в институт - на луну быстрей и дешевле, даже книжки в магазинах - одна донцова и иже с ней... вот и учусь, ЗДЕСЬ задавая вопросы. Я ничего не имею против критики, даже жесткой, о обсирать-то зачем, обидно.

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

← →
AlekVolsk (2011-05-15 00:37) [22]

Перефразируем вопрос по другому.
В одной dll есть модуль данных и на нем TFIBDataSet. В другой dll имеется TDataSource и грид, с ним связанный. Как мне связать TDataSource с TFIBDataSet, без использования трехзвенки, без слияния двух dll в одну? Не важно, зачем и для чего.

> AlekVolsk (15.05.11 00:31) [20]
> о обсирать-то зачем, обидно.

Лично к вам никаких претензий. Хотя вот про книжки только... У вас же инет есть. Можно скачать и учиться. Можно заказать по почте и учиться. В общем главное желание. А отмазки, типа, у меня в соседнем магазине нету, для слабоков. Вон Ломоносов пешком пошел =))

> Как мне связать TDataSource с TFIBDataSet, без использования трехзвенки, без слияния двух dll в одну?
динамически, в процессе инициализации dll, в процедуре которую будешь вызывать при старте. ShareMem естественно, для общего пространства памяти, ну и т.к. dll не будет выполнять свои функции (ты же их жёстко свяжешь, 1 dll с 1 программой. и ни каких "одну dll используют все") то можешь не стесняться и указывать в uses dll модули программы, а в программе модули dll (чтоб был доступ к описаниям форм, хоть какое то удобство). ну а там передаешь "внутрь" форму и

function DllInit(App: TApplication; ProgrForm: TProgrForm): Boolean; begin Application.Handle:= App.Handle; ProgrForm.DataSource1.DataSet:= FIBDataSet; result:= true; end;

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

Логические объекты в виде COM-серверов, объеденённых по какому-либо принципу в dll. У нас такая архитектура была, довольно шустро работала. Как раз для решения задач с "хотелками" различных заказчиков + быстрого наращения функционала.

← →
AlekVolsk (2011-05-15 10:14) [26]

Еще была такая мысть - через интерфейсы, но я с ними сталкивался от силы пару раз, да и com пока тоже не березовая роща. Можно ссылочки на толковую литературу?

> Можно ссылочки на толковую литературу?

У Подгорецкого на сайте что-то было
http://www.podgoretsky.com/

← →
AlekVolsk (2011-05-16 09:32) [28]

Я так думаю, тему можно закрыть. Всем спасибо.

Вынос модуля данных в DLL Найти похожие ветки