Модульность программы, пакеты

← →
девушка (2009-01-15 14:35) [0]

Добрый день!
На данный момент занимаюсь написанием ПО, которое будет состоять из нескольких "Рабочих мест". Например: бухгалтер, менеджер и кладовщик.
У каждого "рабочего места" есть свой набор функций, которые частично пересекаются (например, разные просмотры).

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

Модули с функциями оформлять в виде пакетов (dpk)ю каждое рабочее место будет отличаться своим набором пакетов.

Ранее я я пакеты не создавала, хотелось бы узнать о подводных камнях их использования. Например, как организовывать соединение с БД - создавать ли новое подключения для каждого пакета или можно передать ссылку на уже созданное?
Может есть гораздо лучшие варианты оорганизации приложения?

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

Ниче не понял - какая связь между "пакетами" как "рабочими местами" и функционалом обмена с БД ?

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

Если я правильно понял, то Ваша задача заключается в том, как разделить логику обмена с БД от логики прикладных задач (рабочих мест). А если так, то причем здесь пакеты ?

← →
девушка (2009-01-15 14:46) [3]

Видимо, я не правильно сформулировала.
Требуется сделать приложение и "рабочие места" достаточно гибкими в модификации.

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

← →
девушка (2009-01-15 14:47) [4]

т.е. сделать приложение разбиваемым, а не в одном исполняемом файле.

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

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

Почему нет? Можно и в одном файле. Просто то, что положено видеть кладовщику, кладовщик будет видеть. А что не положено - не будет.

К физическому разделению проекта на пакеты это не имеет никакого отношения.

← →
девушка (2009-01-15 14:52) [6]

> К физическому разделению проекта на пакеты это не имеет
> никакого отношения.

"Руководитель проекта" хочет модульность.
Чтобы уменьшить размер ПО в оперативной памяти и сделать возможними варианты пакетов или dll, например, под разные версии МС офиса.

← →
Ega23 © (2009-01-15 14:59) [7]

> "Руководитель проекта" хочет модульность.

Ну разноси разные фреймы в разные пакеты. Только это не модульность, а фигня какая-то.

← →
девушка (2009-01-15 15:06) [8]

Еще ламерский вопрос - как быть с подключением к БД?

В "ядре" будет TADOConnection, а в пакетах будут датасеты, которые должны (по идее) использовать текущее подключение из "ядра".
Я смогу передать ссылку на TADOConnection в пакет?

(
идея руководителя с отдельным подключением для каждого пакета и передачей строки подключения в пакет - мне очень не нравится :(
)

← →
девушка (2009-01-15 15:09) [9]

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

← →
Anatoly Podgoretsky © (2009-01-15 15:09) [10]

> Ega23 (15.01.2009 14:59:07) [7]

Это не фигня, это верная дорога в могилу. Конечно если получится.

← →
девушка (2009-01-15 15:14) [11]

> Это не фигня, это верная дорога в могилу. Конечно если получится.

обоснуйте пожалуйста, какие могут быть проблемы?
ато у меня идет отторжения этого варианта, но только на уровне интуиции, а интуицию к делу не пришлешь

← →
Anatoly Podgoretsky © (2009-01-15 15:18) [12]

> девушка (15.01.2009 15:09:09) [9]

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

← →
девушка (2009-01-15 15:23) [13]

"главный" выдвигает следующие аргументы:
* у нас есть маломощные компьютеры - будем экономить ресурсы - подгружать только то что нужно, копировать только то что нужно
* в процессе разработки у нас будут части системы часто менятся - не хочется перекомпилировать все "рабочие места" с общими измененными кусками, а просто заменить пакет.
* мне не обязательно будет знать твой код - я буду видеть только интерфейс и подключать пакет (это меня вообще пугает)

> обоснуйте пожалуйста, какие могут быть проблемы?
> ато у меня идет отторжения этого варианта, но только на
> уровне интуиции, а интуицию к делу не пришлешь

Если я правильно понял, то получается, что на каждом месте своя программа, реализуемая через свой набор BPL
В итоге вы получите обычный DLL Hell, только в худшем виде.
Критерии главного не выдерживают критики, это ложные критерии.
Критерием использования BPL/DLL является взаимное использование, строго противоположная вещь.

По критериям

1. экономии ресурсов не будет, будет обратно, поскольку BPL/DLL не даром, а с накладными расходами. Проигрыш даже по дисковой памяти. Это критерии Windows 16

2. Вот тут и получите DLL Hell, при монолитном приложение этого нет. Перекомпиляция в Дельфи очень быстрая и не требует немедленной перекомпляции. Не хочется - это не тот критерий, это критерий лентяя.

3. Наличие пакетов не требует необходимости смотреть чейто код. Дельфи модульная система, к тому же с супербиблиотеками, в отличии от lib/obj и не требует для компиляции исходного кода, достаточно dcu

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

Кстати во времена Вин16 меня очень смущало, что отдельные производители видео карт сували в драйвер все и нужное и нет. Но при переходе на Win32 это смущать прекратило, смущать стало гигантское количество файлов.

← →
девушка (2009-01-15 15:51) [16]

собираю аргументы.

> Наличие пакетов не требует необходимости смотреть чейто
> код. Дельфи модульная система, к тому же с супербиблиотеками,
> в отличии от lib/obj и не требует для компиляции исходного
> кода, достаточно dcu

на этапе разработки "костяка" приложения мне бы ОЧЕНЬ ХОТЕЛОСЬ чтобы мой код смотрели.

>девушка (15.01.09 14:47) [4]
>т.е. сделать приложение разбиваемым, а не в одном исполняемом файле.

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

>девушка (15.01.09 14:52) [6]
>"Руководитель проекта" хочет модульность.

Что вашруководитель вкладывет в понятие "модульность" ?

>Чтобы уменьшить размер ПО в оперативной памяти и сделать возможними варианты пакетов или dll, >например, под разные версии МС офиса.

длл-ки не уменьшают размер ПО в ОПЕРАТИВНОЙ памяти, а вот совокупный объем на диске (или в памяти при одновременной загрузке, что бывает очень нечасто) - уменьшают. Что ему надо - сэкономить место на диске ?

>девушка (15.01.09 15:06) [8]
>Еще ламерский вопрос - как быть с подключением к БД?
>В "ядре" будет TADOConnection, а в пакетах будут датасеты, которые должны (по идее) >использовать текущее подключение из "ядра".
>Я смогу передать ссылку на TADOConnection в пакет?

Что Вы подразумеваете под словом "пакет" ?

>идея руководителя с отдельным подключением для каждого пакета и передачей строки подключения в пакет - мне очень не нравится :(

Что Ваш руководитель подразумевает под словом "пакет" ?

>девушка (15.01.09 15:23) [13]
>"главный" выдвигает следующие аргументы:
>* у нас есть маломощные компьютеры - будем экономить ресурсы - подгружать только то что >нужно, копировать только то что нужно

Пакеты не помогут. Кардинальное решение - тонкий клиент

>* в процессе разработки у нас будут части системы часто менятся - не хочется >перекомпилировать все "рабочие места" с общими измененными кусками, а просто заменить >пакет.

Тут пакет "в тему". Но не единственное решение. Как вариант - ддл-ки. Если все пользовательские ПК в локаотной сети, что нет надобности хранить сами приложения на их ПК - достаточно выложить их на расшаренный ресурс - там и обновлять. Если пользователи удаленные, то трехзвенка. Меняется только АПП-сервер, но не приложения. Опять же смотря какие "куски" меняются - если "базовые", то пакеты не помогут - практика показывает, что ревизии в таких случах подлежит весь проект (приложение) в целом

>* мне не обязательно будет знать твой код - я буду видеть только интерфейс и подключать пакет (это меня вообще пугает)

Ничего страшного. Вполне реализуемо без пакетов. Т.е. на польовательском ПК приложение устанавливается (переустанавливается) без участия разработчика. Это сплошь и рядом

> девушка (15.01.2009 15:51:16) [16]

Не мешает, если dcu/pas лежат рядом, то можно и посмотреть, если есть желание обеих сторон.
Но это не обязательно, не хочет знать, просто не надо смотреть.

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

Думаю, Вам будет интересно почитать ибо в тему:
http://delphimaster.net/view/15-1231918204/

Модульность программы, пакеты Найти похожие ветки