Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» проектирование взаимодействия библиотек в delphi xe2

Автор: druff
Дата сообщения: 23.02.2012 12:03
Очень хочу получить информацию в любом виде (советы, личный опыт, ссылки на статьи или блоги, просто ключевые слова для поиска) о правильном проектировании взаимодействия библиотек/модулей при кодинге под Delphi XE2 (постепенно перехожу с Turbo 2006, но в старом проекте этой теме уделял очень мало внимания, поэтому практически с нуля учусь)

вот пример 1:
есть библиотека libА, в которой описаны классы classA1, classA1List, classA2, classA2List и объекты objectA1List (список объектов classA1) и objectA2List

Вопрос: как правильно (можно несколько вариантов?) в библиотеки libB получить objectA1List и objectA2List из библиотеки libA?

пример 2: похож на предыдущий, но усложняется тем, что в библиотеке libB нужно запустить алгоритм из библиотеки libA, который будет ещё и визуальные формы отображать, но потом всё равно вернёт списки объектов.

вот и тут меня накрывает лавина вопросов, как всё это реализовывать. Нужно ли использовать интерфейсы.. Нужно ли выбирать между dll и bpl.. и т.д. и т.п.

п.с. есть особенность, в будущем, хотелось бы иметь возможность разнести эти две библиотеки по разным компьютерам, т.е. libA будет сервером приложений а libB - клиентом (в этом случае пример2 не будет нужен, конечно). Поэтому хочется спроектировать приложение так, чтобы это разделение в дальнейшем произошло с минимальными затратами.
Автор: salexn1
Дата сообщения: 23.02.2012 12:35
druff
По мне это просто супер реализовано в... C#
Хоть сам и фанат Delphi, но в C# это красивее все сделано.
Автор: druff
Дата сообщения: 23.02.2012 12:46
salexn1
Жаль, но шарп не подходит по многим причинам. Интересует именно делфи.
Автор: A_V
Дата сообщения: 23.02.2012 16:19
druff
если нужна слабая связанность, то, да, использовать интерфейсы.
можно еще в сторону spring посмотреть в плане DI
Автор: druff
Дата сообщения: 23.02.2012 17:30
A_V
мерси, только по этим нескольким словам нашёл несколько полезных блогов, буду разбираться. Вообще смотрю после выхода D2010 начали появлятся новые фреймворки..

Кстати по поводу блогов.. их все можно найти на delphifeeds (забугорном и нашем)? Или есть полезные ресурсы там не представленные?
Автор: delover
Дата сообщения: 28.02.2012 05:46
druff
Да я тоже согласен с salexn1 - в Си# это достаточно красиво сделано, однако по сути всё то же самое есть и в Delphi. Например Windows Comunication Foundation реализует одну общую dll на сервере и клиенте. dll по сути пустая она содержит только опубликованные интерфейсы объектов которые могут быть использованы в протоколе WCF между сервером и клиентом. В дельфи всё есть для этого, только синтаксически не до конца оформлено. Советую глянуть в сторону RTTI и свойств в секции published. Свойствами можно так же оформить dll для связи библиотек.
Автор: salexn1
Дата сообщения: 28.02.2012 09:25
delover
druff
В С# не нужно с собой таскать dcu или pas. Все внутри сборки, подключил сборку и вуаля: тебе доступны классы сборки. В дельфях это все сложнее...
Автор: druff
Дата сообщения: 28.02.2012 09:38
salexn1
а в делфи их нужно таскать?
Автор: salexn1
Дата сообщения: 28.02.2012 10:03
druff
Да, нужно.
Как минимум DCU.
Но не для конечных клиентов, конечно.
Автор: druff
Дата сообщения: 28.02.2012 10:10
salexn1
в каких именно случаях? билд/exe может потребовать наличие dcu для работы? Или что?
Автор: delover
Дата сообщения: 28.02.2012 10:19
druff
В билдах не надо но если требуется я так понимаю распространение библиотек для разработки то требуется минимум dcu и интерфейсная часть файла pas. Но такое давно не практикуется так как даже одна версия delphi может содержать различные патчи и не факт что версия vcl будет той же что и у dcu файлов.

Однако salexn1
Так все исходники валяются внутри сборок и легко выдираются спомощью ILSpy иже с ним.
Автор: salexn1
Дата сообщения: 28.02.2012 10:34
delover
Таки да, только если обфускатором не пройтись...
Автор: druff
Дата сообщения: 28.02.2012 10:41
Это всё касается варианта с использованием интерфейсов?
Автор: salexn1
Дата сообщения: 28.02.2012 11:51
druff
Какая разница: интерфейсы или нет.
Другое дело, что сами файлы интерфейсов - их объявление - никому не интересны и сами по себе бесполезны, по-этому могут быть отданы в открытом виде.
Пример, чтобы понять:
в C# создали сборку, в которой есть класс А и есть метод Foo. Собрали ее. Теперь создаем другой проект, подключаем сборку и пишем:
...

var A = new ClassA();
A.Foo();

сорцы не нужны. Все внутри сборки.

В Delphi создали BPL и все равно нужны либо сорцы либо DCU.
Вы не напишете

a := TClassA.Create;
Автор: delover
Дата сообщения: 28.02.2012 12:24
salexn1
Дело в том что они нужны только на этапе разработки и только разработчику. BPL в принципе та же dll, но только для сборки возможно гетерогенное наследование в другую BPL. В принципе в .NET реализовано то же самое в виде DLL. И про класс А и про Foo точно так же не знает и не подозревает никто кроме разработчика, так что преимущество тут весьма сомнительное. Зато вариант с обфускатом, решили вы например продавать прогу на C#. Ну купил её у вас один пользователь, другой пользователь скопировал и прошёлся обфускатом, вытащил все исходники и прекрасно перекомпилил те места где установлена Ваша защита. Можно поздравить - программа уже стала бесплатной. Так что про защиту практически можно и не думать.

druff
Я писал ещё немного другое про паблишед свойства. По ним можно создавать объекты с динамическими свойствами. То что реализовано в WCF. Зачем это нужно - гораздо более высокая масштабируемость серверов. Они могут обладать более новыми версиями протоколов не влияя на работоспособность старых клиентов. Т.е. это технологии XMLRPC. Вот по ним то совершенно точно можно писать TClassA.Create который будет работать далеко на сервере, так как описания классов всегда можно посмотреть в xml-ке которую возвращает сервер.
Автор: druff
Дата сообщения: 28.02.2012 13:27
salexn1


Цитата:
var A = new ClassA();
A.Foo();


да, удобно.

delover

и как библиотека B узнает о классе TClassA? Нужно сделать хидер-файл с описанием классов или как то ещё?
Автор: delover
Дата сообщения: 28.02.2012 14:08
druff
Да

Цитата:
Нужно сделать хидер-файл с описанием классов

На сервере и клиенте как делает WCF
Или использовать XML описание как делает XMLRPC/WebSnap
Или третий вариант использовать оба предыдущих

Добавлено:
Более красивым мне кажется первый вариант (он экономичнее к трафику)
Автор: salexn1
Дата сообщения: 28.02.2012 14:16
delover
а если без XML?
тупо есть библиотека LibA.bpl и мне нужно из нее заюзать класс ClassA?
Без dcu\pas - никак!!!!

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

druff
Если вы не собираетесь распространять свои классы, чтобы можно было создавать обмен данными, то не загоняйтесь и делайте, как и раньше - без BPL

Возьмите на вооружение принцип - один класс - один файл, как можно меньшую связность между классами и все будет гуд
Автор: wasilissk
Дата сообщения: 28.02.2012 14:48
А зачем вообще может понадобиться выносить часть функционала в dll/bpl? Именно если одним разработчиком разрабатывается и dll и exe?
Сам когда-то страдал чем-то подобным, написал морду в exe, которой можно было скармливать bpl-ки, содержащие собственно функционал. В итоге получил кучу гемора из-за сложно вылавливаемых багов с менеджером памяти, крайне неудобной отладкой – 2007ая при отладке "build with runtime package" просто вылетала в самых интересных местах, тупо отрубала все брейкпоинты до полного ребилда. Количество кода при добавление нового функционала увеличилось порядком. Единственный плюс, это то, что получился полный MVC как в книжках. Через полтора года переписал все это дело без использования bpl (тем более что покупатель, которому нужен был функционал нескольких bpl одновременно, было всего один) и ни разу об этом не пожалел.
Или вы о каком-то другом применении?
Автор: druff
Дата сообщения: 28.02.2012 14:51
delover
может какой ресурс для изучения посоветуете?

salexn1
меня больше интересует именно обмен данными/объектами. Пример с C# интересен, но для себя решил, что такие классы, которые будут требоваться во всех библиотеках, буду включать на этапе компиляции. Т.е. отдельный каталог (shared), который будет подключён ко всем .dpr и в котором будут лежать описание/реализация всех общих классов
Автор: delover
Дата сообщения: 28.02.2012 16:51
wasilissk
Полностью согласен BPL оправдывает себя только для дизайна у C# гораздо мощнее поддержка сборок. И это действительно факт. Однозначно exe/dll. Либо exe и только свои BPL в каталоге.

druff
В Delphi я XE2 не знаю, мне рано ещё туда - стаж всего 20 лет. Но в DEMOS старых версий я видел папку AttributesAndRTTI и это самое увлекательное на мой взгляд для изучения. Ну и надо знать что-то типо двухуровневых компонентов как INI файл. Сервер интерфейс и CALLBACK клиент интерфейс обмениваются массивами или единичными объектами. А префиксом обмена является действие которое надо совершить - этого за глаза хватит чтобы писать свой ICQ и даже маломальскую игруху.
Автор: druff
Дата сообщения: 28.02.2012 17:15
wasilissk

Цитата:
А зачем вообще может понадобиться выносить часть функционала в dll/bpl? Именно если одним разработчиком разрабатывается и dll и exe?


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

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

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

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


а второй нюанс, как я писал в самом первом сообщении - для дальнейшего вынесения логики в сервер приложений. Чтобы тонкий клиент запрашивал у сервера список объектов, человек производил с ними действия (просмотр, редактирование) и отправлял изменения обратно. Но это к первой части ответа не имеет отношения т.к. здесь будет разделение приложения на два больших куска, а не выделение некоторых сервисных функций
Автор: wasilissk
Дата сообщения: 28.02.2012 17:56
druff

Цитата:

- проверка лицензий
- управление правами пользователей
- система обновлений
- чтение различных настроек

Угу всем этим у меня тоже занимался common.bpl (кроме проверки лицензий, это как-то имхо несекьюрно). Но как показала практика гораздо удобнее весь этот функционал просто продублировать в нескольких проектах.
Про второе вообще не понял, зачем это нужно. Для обновления чтоли?
Автор: druff
Дата сообщения: 28.02.2012 18:28
wasilissk

Цитата:
Но как показала практика гораздо удобнее весь этот функционал просто продублировать в нескольких проектах.


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


Цитата:
Про второе вообще не понял, зачем это нужно. Для обновления чтоли?

Ну нет, речь идёт об обычной многозвенной архитектуре. Когда СУБД стоит на одном сервере, сервер приложений на другом(других) а клиенты подключаются не к серверу БД, а к серверу приложений. У этой схемы есть много преимуществ (простота реализации не в их числе )
Автор: salexn1
Дата сообщения: 28.02.2012 18:32
wasilissk
druff
все проблемы из-за "недорешений" delphi.
в C# это решено очень классно: берешь сборку из SharePoint, подключил к своему проекту и юзаешь их сущности.
Автор: wasilissk
Дата сообщения: 28.02.2012 18:45

Цитата:
Такая схема сделана на случай, когда у одного заказчика стоит несколько АРМов и он хочет, чтобы база юзеров была единой. Поэтому и у ядра есть своя небольшая база данных.

Это я понял. Но ничего ведь не мешает писать в одну БД из двух разных приложений, у меня сейчас так и работает.

Цитата:
Ну нет, речь идёт об обычной многозвенной архитектуре.

Ах вот оно как!?
Работающих трехзвенок на Delphi еще не видал, простота реализации уж точно не их заслуга. Ну чтож удачи!

Добавлено:
salexn1
Я как раз и считаю, что Delphi тут не совсем (или даже "совсем не") к месту.
Автор: druff
Дата сообщения: 28.02.2012 18:56
salexn1
ну почему сразу "недорешений" и почему именно делфи? разве в C++ не такие же проблемы? И с другой стороны, C# разве уникален в этом? Джава, питон и прочие высокоуровневые языки тоже это умеют.
Автор: druff
Дата сообщения: 28.02.2012 21:45
wasilissk

Цитата:
Но ничего ведь не мешает писать в одну БД из двух разных приложений, у меня сейчас так и работает.


думал над этим. Если представить ситуацию, когда:
заказчик1 имеет только приложение1
заказчик2 имеет только приложение2
заказчик3 имеет приложение1 и приложение2
и оба приложения хранят данные в единой базе, то возникает дополнительные сложности с обновлением заказчиков(все трое должны получать обновления и приложения1 и приложения2) и разработкой приложений (если приложение1 и приложение2 разрабатывают разные люди/команды)


Цитата:
Работающих трехзвенок на Delphi еще не видал, простота  реализации уж точно не их заслуга. Ну чтож удачи!  

я занимался небольшой 3х звенкой, но именно что небольшой (малюсенький кусочек функционала от основного проекта). И технологии использовались такие же мрачные: обычный XML гонялся в обе стороны, никакого SOAP, JSON и прочих прелестей.
Автор: salexn1
Дата сообщения: 28.02.2012 21:58
druff
MIDAS - это и есть 3-х звенка.
Работает все неплохо. Кроме одного - в каждый проект, приходится тягать кучу сорцов...
Автор: druff
Дата сообщения: 29.02.2012 11:27
salexn1
насчёт MIDAS не знаю. Но вот если SOAP, то всё описание будет лежать в XML файле вместе с сервером.

Страницы: 12

Предыдущая тема: Сравнение файлов на VBScript


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.