У Марко Кэнту почитал материал "Динамические пакетные архитектуры". Все бы ничего, но ни слова про БД.
Вопрос: ряд  организаций (например, кто ваяет а-ля ERP) использует эту методику (bpl + интерфейсы).
Принципиально, посыл понятен: обновляем то - что изменилось: не более (типа экономим трафик./+гибкость). Ну а на практике выгода есть?


Если у Кого есть реальный опыт, буду очень признателен за консультацию.
<b/>

Не очень понятно, что разделять по пакетам. Например, у меня есть модули (очень условно): Склад и Бухгалтерия (MyUglyERP). Это отдельные пакеты или степень "гранулированности" (на практике) еще глубже(
Типа, модуль Приходные накладные - один пакет, расходные - другой, и т.д. и т.п.)???

Извините, я неправильно задал вопрос или еще что?

Смотри .Net или 1с - там всё, как тебе нужно. Можно хранить в БД - 1с так и делает.

я использую bpl, но не понимаю, какое отношение это имеет к базам данных.
bpl это просто набор юнитов, связанных чем-то (кто чем связывает).

> Это отдельные пакеты или степень "гранулированности" (на
> практике) еще глубже(

смотря о какому принципу гранулировать.
если с точки зрения грантов, то еще глубже.
а по пакетам бить по принципу "что чаще вместе используется", принцип
в первом приближении хорош более чем.

> tesseract ©   (24.03.11 23:02) [2]
>
> Смотри .Net или 1с - там всё, как тебе нужно. Можно хранить
> в БД - 1с так и делает.
>

1С - не динамическая и не пакетная. Например, нельзя динамически, подключать документы, или, скажем справочники с регистрами. Внешние обработки и отчеты - это не серьёзно.
Нельзя разрабатывать модули для конфигурации, не имея исходников этой конфигурации ("на интерфейсах"). Нельзя выдернуть модуль из торговли и прикрутить его к бухгалтерии без 100% переписывания кода.

2Автор.

Пакеты - это технический инструмент, аля модули, циклы, и  прочие примтивы.

Изложу свой опыт.

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

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

Также пакеты - хороший инструмент плугинизации расширяемых задач.  На этом все IDE Delphi построено.

При этом надо помнить, что BPL - это DLL, и формат того, что экспортирует BPL не документирован. Я бы не решился менять пакет, который явно прописан в секции requires другого пакета или в списке runtime packaes приложения...

Дмитрий Тимохов   (25.03.11 02:15) [6]

зачем смущаешь неокрепшые умы ?

> Handbrake   (23.03.11 23:56)  
>  Динамическая пакетная архитектура и БД


Каким образом пакетная архитектура связана с БД?

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

Пакеты могут работать с БД, а могут и не работать. Как напишете - так и будет. Главное в пакетной архитектуре - это хорошо продумать, какой именно функционал остается в ядре, а какой выносится в пакеты (и зачем он туда выносится). Потом надо продумать интерфейс пакетов, где они будут храниться, как и когда они будут загружаться, будут ли они в дальнейшем расширяться/обновляться... и т.п.

> Handbrake   (23.03.11 23:56) 

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

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

> Короче кофеварка не может превратиться в сковородку и наоборот.


Одноразово еще и не то можно сделать :)

> Handbrake   (23.03.11 23:56)  
У меня практика внедрения ERP 8 лет. Далее по тексту идет мое личное мнение. Оно не является истиной в последней инстанции.

На практике лучшие движки ERP- это скриптовые машины как, например, машина java, или движок 1C, или WindowsShellHostScript, в общем все то, что позволяет исполнять скрипты "на лету".

Лично я  - сторонник монолитного ядра (лично у меня оно сейчас весит 8 метров), которое по сути своей - бесполезно (как бесполезен Excel, пока вы не спроектируете в нем ваш "Лист1" с формулами) и не более чем как компилятор и/или интепритатор некоего объектного языка. А вот уже средствами этого языка пишется конфигурация - набор модулей для решения прикладной задачи.

Второе, по поводу "пакетности". На практике пакетность - это полная хрень, ограниченно применимая, ибо в ERP с течением времени пользования системой (достаточно год-полтора) объекты становяться очень сильно связаны между собой, бывает даже так, что переплетены по нескольку раз. И уже выделить объекты в некие обособленные модули становиться невозможным.

Бывает даже так, что мы в продакшене отказываемся от некоторых заказов в виду того, что потенциальный клиент просит "мне все не надо, а только вот модуль САПР для расчетов и модуль РаспределеннойБД". А мы не можем выделить ему модуль САПР, ибо цена рассчитанного изделия напрямую зависит от цен в справочнике ТМЦ на комплектующие (подсистема "Склад"), курса валют НБУ (другая подсистема), и скидки контрагента (подсистема "CRM"). Вот и получается, что для того, чтобы система работала нормально, нужно поставлять все модули.

Да и вообще модульность - ИМХО изобретение маркетологов, и если модульность в прикладном ПО позволяет купить заказчику только то, что ему нужно (снижение стоимости), то в ERP - это лишь способ "дожать" с заказчика еще денег. ERP не может работать по-модульно, ибо тогда теряется ее суть: комплексность работы с данными.

Лично я понимаю, откуда у вопроса ласты растут: выполнение обновлений. В описанном мною случае обновление - это просто *.7z архив, содержащий текстовые файлы (исходный код модулей на языке движка). Иногда требуется изменение структуры БД - добавление таблиц, полей. Тогда пакет обновлений содержит еще и файлы с расширением *.SQL, которые выполняют изменения в БД.

И последнее. Некоторые SQL-сервера или СУБД могут работать с BLOB данными, что позволяет хранить модули работы с данными на скриптовом языке прямо в базе данных, что на практике дает возможность единоразового централизованного обновления системы. В то время как с *.BPL админу заказчика придется бегать по всем этажам, переустанавливая exe-шник. На нормальном машиностоительном заводе это может быть около 400-500 ЭВМ, разбросанных в зданиях по достаточно большой территории.

О, тут такие ужасы рассказывают. Возьму на ночь почитать.

> PEAKTOP ©   (25.03.11 17:40) [11]

как в java выполнить "скрипт на лету"?

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

После разделения на пакеты отпала необходимость перекомпилировать основное ядро.
Все пакеты представляют собой дочерние формы, которые имеют одного родителя. Родитель обладает всем общим функционалом по логгированию, обновлению, раздаче прав доступа. Родитель имеет несколько основных наследников, которые представляют готовые решения тех или иных форм(многоэкземплярная форма, одноэкземплярная форма, форма с уникальными параметрами). Каждая форма имеет привязку к конкретному модулю и знает, кому она принадлежит. Также она имеет в себе структуру параметров для личного использования, которые задают ее исходные данные, характер поведения/отображения.
Раздача прав доступа возможна как по модулям, так и по отдельным контролам в форме. Тоже самое касается обновления: возможно обновление модуля непосредственно перед его вызовом без перезагрузки родительского главного окна.
Тяжелые запросы выполняются в потоках, чтобы не залипал весь интерфейс из-за одной формы.
Есть панель задач, которая облегчает навигацию между открытыми окнами.
Из плюшек - скины и поддержка родных тем винды.

Пользователей порядка 1200 единиц. 20 групп доступа.

> На практике пакетность - это полная хрень, ограниченно применимая,
>  ибо в ERP с течением времени пользования системой (достаточно
> год-полтора) объекты становяться очень сильно связаны между
> собой, бывает даже так, что переплетены по нескольку раз.
>  И уже выделить объекты в некие обособленные модули становиться
> невозможным.


на практике можно руки выпрямлять. крайне способствует

>  В то время как с *.BPL админу заказчика придется бегать
> по всем этажам, переустанавливая exe-шник.

у меня эти *.BPL  тоже в блобе хранятся, и никто ни за кем не бегает)))

> После разделения на пакеты отпала необходимость перекомпилировать основное ядро.

Здесь явная ошибка разработчиков: ядро не должно нести в себе бизнес-логики. Тогда его нужно перекомпилировать раз в 100 лет, когда "созревают" новые компоненты и/или расширения скриптового языка.

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

> у меня эти *.BPL  тоже в блобе хранятся, и никто ни за кем не бегает)))
Оригинально. =)) Тоже замечательный выход из положения. Тогда получается, что файл "main.exe", который потом дергает эти *.BPL, создается "на века" ? Ведь по сути, если есть соглашение синтаксиса вызова интерфейсов из BPL, то несущее ядро "main.exe" менять не нужно.

> Здесь явная ошибка разработчиков: ядро не должно нести в
> себе бизнес-логики.

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

> Тогда получается, что файл "main.exe", который потом дергает
> эти *.BPL, создается "на века" ?

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

Но это все нюансы.
Основная мысль в том, что не нужно браться так категорично рассуждать, как  PEAKTOP ©   (25.03.11 17:40) [11], если нет соответствующего опыта.

С уважением.

> Здесь явная ошибка разработчиков: ядро не должно нести в
> себе бизнес-логики.

А что это без бизнес-логики наворочено в 8 мег?


> Тогда получается, что файл "main.exe", который потом дергает
> эти *.BPL, создается "на века" ?

А чего б его не создать "на века", если в нём 17 строчек кода?

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

Пакетная архитектура - это как сундук с инструментами. Положил всё, что нужно, пошел работать. Чего-то не хватает - доложил не заморачиваясь. А монолитное ядро на все случаи жизни - это швейцарский ножик - всё в одном. Только швейцарским ножиком дом никогда не построить. Разве что, скворечник.

Хороший пример пакетной архитектуры - это Delphi

Ну вот, а еще говорили про неокрепшие умы + какая связь БД и bpl:).

Посмотрите, какая дискуссия развернулась между Вами (Зубрами, поди).

Все примеры, какие я видел в сети, касаются плагинов: подключаем, типа, кучу кодековневажночего (сколько надо - столько и подключим). Да нет базара! Они ни чем не связаны. Посему, очень для меня актуально:

> по поводу "пакетности". На практике пакетность - это полная
> хрень, ограниченно применимая, ибо в ERP с течением времени
> пользования системой (достаточно год-полтора) объекты становяться
> очень сильно связаны между собой, бывает даже так, что переплетены
> по нескольку раз. И уже выделить объекты в некие обособленные
> модули становиться невозможным.

Вот и я про это и подумал вперед.

Спасибо большое Всем за мнения, если еще чего будет, почитаем с удовольствием.


Ну а в общем, суть вопроса уточняется, т.е. динамические пакетные архитектуры (читай модульность) в применении к логически взаимосвязанным объектам/процессам (т.е., не обязательно БД).

> DiamondShark ©   (25.03.11 19:39) [19]
>> Здесь явная ошибка разработчиков: ядро не должно нести в себе бизнес-логики.
>
> А что это без бизнес-логики наворочено в 8 мег?


Там только голая скриптовая машина. Даже дизайнер объектов уже писан средствами скриптовой машины.

А весит до фига куча компонентов. Из самописного там
1) Библиотека симпатичных контроллов на все случаи жизни.
2) Библиотека для отчетов (чего-то похожее на QReport, но безбожно допилиное под свои нужды).
3) Библиотека доступа к Firebird.

Плюс ко всему сторонние компоненты:
1) TeeChart (не тот что из Delphi, а полный).
2-4) Библиотеки доступа к данным для Слонопотама и МуСКуля.
5) EhLib.

Особенно тяжелый - это TeeChart.

> >|<   (25.03.11 19:39) [18]
>
> Основная мысль в том, что не нужно браться так категорично рассуждать, как  PEAKTOP ©   (25.03.11 17:40) [11], если нет соответствующего опыта.

Мой пост под номером [11] начинается со слов:

У меня практика внедрения ERP 8 лет. Далее по тексту идет мое личное мнение. Оно не является истиной в последней инстанции.

Вы невнимательны.

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

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

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

а будет ли это сделано пакетами - вопрос пятидесятый.

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

Когда в 2006-м году брался за первую систему, которую захотели переделать в виде подгружаемых модулей, тоже наступал на эти грабли.
Модули просто не хотели грузится. Окно сообщений содержало что-то типа "Module <name> already contains in Module2.bpl".
Поэтому как раз модульная архитектура и заставляет все упорядочить, чтобы не было переплетено по нескольку раз. Иначе модуль банально не загрузится.
А в обычных мегапроектах в секциях uses без разбору пихают до кучи разных модулей, в которых многие ф-ции реализованы по сто раз. И прочий бардак, связанный с текучкой  в команде разработчиков, когда каждый новый программист вносит с собой новый хаос в исходники.

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

> >|<  (28.03.2011 12:51:27)  [27]

Хелсберга не уберегли.