Midi окна из dll дайте направление движения

← →
sniknik © (2008-01-09 09:08) [40]

> Все ссылки на частичное обновление не выдерживают критики, будет обычный dll hell.
вот про то и речь. наверное. только для bpl, и с практической стороны.
всего одна программа такая на поддержке, не нашим отделом писанная, слава богу, а проблем от нее больше чем от всех остальных вместе взятых. или, вернее с ней.
и дело не только в "разноверсионности" частей, это хоть и убого но легко обходится обновлением всего, как писал. тут еще и, т.к. структура программы, так понимаю, получается более запутанной изза итого модульного принципа, а значит вероятность ошибок больше (что подтверждается практикой), и бывают вообще уж идиотские ситуации, изза попыток сделать каждый модуль(плагин) более автономным, бывало что одну настройку необходимо было прописывать в трех местах... и не дай бог ошибиться и прописать разные значения.
вообще проект начинался как "огого, какая у нас крутая программа будет! вся из кирпичиков, что клиент захочет то и будет составлено, может все! функционал достраиваемый, даже если не может сейчас будет дописано, и подключено добавлением всего одной bpl!", а на деле получилась самая глючная, и неповоротливая программа, изменение для одного клиента фактически "отпочковывает" новую не совместимую с паралельными ветвь (т.е. все с точностью до наоборот от желаемого), т.к. желания клиентов они обычно такие непредсказуемые... не предусмотренные протоколом плагинов сделанным два года назад... а т.к. общая структура модульная то новый модуль с новым протоколом(старый не исправишь чтобы другие не "отвалились", или переделывать все) тянет за собой и изменение "ядра", и т.д. действительно "ад".
хотя в общем прога ничего особенного, легко можно было написать и обычным способом (плагины там явно "притянуты за уши" ради вот этих вот "благ", удобства, и т.д. которые не сработали)

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

← →
206196131 © (2008-01-09 14:56) [41]

> Да и когда же ты начнешь читать книжки?

уже

← →
206196131 © (2008-01-09 15:23) [42]

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

← →
Amoeba © (2008-01-09 16:43) [43]

> 206196131 © (09.01.08 15:23) [42]
>
> так пацань тема закрыта
> нет смысла дальше продолжать разговор, тк каждый учиться
> на своих граблях))
>

Ох и много будет этих граблей ...

← →
206196131 © (2008-01-09 18:26) [44]

> Ох и много будет этих граблей ...

я и не спорю, но так как других предложении по существу нет буду делать так как я это себе вижу

← →
Loginov Dmitry © (2008-01-09 21:34) [45]

> Суть ДЛЛ в использование их многими программами, если же
> программа одна, то это уже не суть, а извращение. Все ссылки
> на частичное обновление не выдерживают критики, будет обычный
> dll hell.

У каждого должно быть свое мнение на этот счет. Позвольте высказать свое.
Можно вести речь о том, что dll - это зло и все такое только для примитивнейших систем, где совершенно очевидно, что все можно сделать в одном exe-шнике. Если система простая, то согласен, что нет смысла разбывать на кучу модулей. Если система сложная, но разрабатывается одним человекам, то смысла разбивать вероятно (но с натяжкой), также нет! А вот если система разрабатывается командой, и сложность у нее ОЧЕНЬ высокая, то реализовать все в одном модуле - нет НИКАКОЙ возможности. Т.е. это возможно, но ТОЛЬКО теоретически. Я не могу знать абсолютно всё, и каждый из отдельных членов команды также все не знает! Я делаю головную программу. Она должна работать, скажем, с ключами iButton. Но мне совершенно параллельно, что это такое, и не интересует, как с ними работать, к томуже на то, чтобы разобраться, времени нет! Но я точно знаю, что когда ключик прикладывают к контактной площадке, моя программа должна на это реагировать: считывать код ключа, записывать или считывать данные с него. Соответственно, кому-то поручается работа с ключами. Человек делает библиотеку с тремя функциями - чтение номера ключа, запись данных на ключ, чтение данных с ключа. Далее система устанавливается у клиента. Если требуется доработать / исправить библиотеку, то дорабатывается только она. Если требуется доработать головное приложение, то дорабатывается только оно. Соотвественно, у клиента обновляется только та часть, которая ему нужна. Нет никакого смысла обновлять всю систему.
Далее... Система взаимодействует с оборудованием. Например - с ТРК. Нужно чтобы система по возможности работала со всеми типами ТРК. Их много. Скажем 20 - 30 шт. У каждого типа ТРК свой протокол обмена. Протоколы постоянно меняются, дорабатываются - за этим нужно своевременно следить и вносить изменения. Единственный разумный способ взаимодействия с ТРК - написание индивидуальных драйверов. Получаются небольшие dll-ки размером до 50 Кбайт. Пускай их 20 штук. Но с ними работать в 20 раз проще, чем если бы все они располагались в одном модуле. Покупает клиент себе новую ТРК - вносятся необходимые изменения в один-единственный файл, и только его клиент обновляет. Это кстати был пример, когда деление на модули выручает даже если над системой работает всего один человек, и справедливо не только для ТРК, но и для другого оборудования (кассы, платежные терминалы, дисплеи покупателя и т.д.). Смешивать работу с различным оборудованием в одном модуле - вот ЭТО - ИЗВРАЩЕНИЕ.

Так что единственным правилом, по которому принимается решение о разбивке на модули, является удобство ральнейшего сопровождения системы. Если смысл разбивки ЧЕТКО не осознан, то не стоит приниматься за это дело - все равно толку не будет НИКАКОГО. Если же смысл есть и он осознан - надо разбивать. Все модули во всё время работы системы должны быть совместимыми. Т.е. обновление любого модуля без обновления остальных модулей не должно ухудщить работоспособность системы. Обновления должны улучшать работоспособность системы, но никак не ухудшать. Для этого нужно иметь определенные навыки. Если же доработка модуля приводит к обновлению всех модулей системы (и так каждый раз), то это говорит о том, что у человека недостаточно опыта разрабатывать многомодульную систему, и тут действительно лучше делать все в одном модуле. При работе с плагинами следует максимально полно реализовать обмен данными между модулями. КАЖДАЯ библиотека ОБЯЗАНА уметь возвращать номер версии (желательно целое число). Даже если возможности библиотеки сейчас однозначно определяются набором экспортируемых процедур, рано или поздно номер версии все-равно понадобится. Головное приложение также обязано предоставлять номер версии любой библиотеке. Если в модуль добавляются новые возможности, то следует увеличивать номер версии, а перед использованием этих новых возможностей следует запрашивать номер версии модуля - это определяет, включена ли данная возможность в модуль, или нет. Только так можно избежать эффекта, о котором говорится в [34], т.е. необходимость обновлять всю систему при обновлении какой-то ее части.

← →
sniknik © (2008-01-09 22:58) [46]

Удалено модератором
Примечание: дубль

← →
sniknik © (2008-01-09 22:59) [47]

Loginov Dmitry © (09.01.08 21:34) [45]
а ты разницы не замечаешь? твоих примеров и авторского начинания (по аналогичной технологии та о котороя я "возмущался")

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

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

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

← →
Loginov Dmitry © (2008-01-10 07:58) [48]

> оба твоих примера - драйвера работающие с устройствами,
> т.е. именно то для чего dll-и и служат. повсеместно

Все эти устройства работают через СОМ-порт, посему при остром желании можно все зафигачить в один модуль (эти модули являются "драйверами" для системы, а не для Windows).

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

А причем тут двери? :) iButton"ы разве нужты только чтобы двери открывать? :)

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

Я не внушаю никакие "ложные" надежды. Надеюсь, автору это понятно из последнего абзаца [45], и из нашего обсуждения он сделает для себя вывод, стоит ли тратить время на подобные разбиения.

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

← →
sniknik © (2008-01-10 09:14) [49]

> А причем тут двери? :) iButton"ы разве нужты только чтобы двери открывать? :)
а ты разве не про такую систему которая у нас на проходной, приложил электронную карточку, и дверь открылась. в одном случае, в другом турникет разблокировался. а заодно и учло кто куда пошол.
нет? ну неважно, принцип от этого не страдает, это драйвер устройства.

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

← →
206196131 © (2008-01-10 21:14) [50]

> Насчет адекватных примеров ...

1C чем тебе не адекватный пример, хоть там не DLL но всеже идея как раз отсюда

> 1C чем тебе не адекватный пример, хоть там не DLL
правильно, не dll а ActivX (COM), который как раз для этого и предназначен.

> но всеже идея как раз отсюда
возми оттуда же и способ реализации, и у тебя тоже будет адекватно.

> sniknik © (11.01.08 01:34) [51]

+1

Это кстати и к Loginov Dmitry © (09.01.08 21:34) [45]
относится. Хотя в его случае никакой особой разницы нет, в отличие от случая автора сабжа.

> sniknik © (11.01.08 01:34) [51]

м почему эти технолигии всплыли только сейчас )))

> относится. Хотя в его случае никакой особой разницы нет,
> в отличие от случая автора сабжа.
>

Это ты к чему ?

> м почему эти технолигии всплыли только сейчас )))
телепатор сломался потому что.

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

Midi окна из dll дайте направление движения Найти похожие ветки