Каков наилучший способ обмена данными приложений в Delphi без сокетов?
Мне нужно несколько моих связанных приложений для связи друг с другом (обмен данными и инициирование действий). Требования без пакетов и без гнезд. Поэтому я предполагаю, что оставляет именованные каналы, WM_CopyData (например, Skype) и параметры команды. Каковы ваши лучшие практики?
8 ответов
У вас, вероятно, есть несколько вариантов.
сверх того, что у вас уже есть:
DDE
Сопоставленные с памятью файлы (MMF)
Слоты
Я бы, вероятно, пошел с трубами или MMF.
есть несколько бесплатных компонентов MMF, которые вы можете скачать, Deborah Pate имеет набор бесплатных классов, которые вы можете использовать. MapFiles.zip
проверьте наличие MailSlots на Тори сайт.
финал решение может зависеть от количества, размера и частоты передачи данных, которые решают, какой вариант вы выберете.
Я бы посоветовал использовать COM в этой ситуации. (Внимание: не COM+, не ActiveX, не OLE; COM, просто COM.)
поскольку Delphi 7 (или более ранняя версия, я не уверен), это легко сделать, добавив библиотеку типов в проект и объект автоматизации.
преимущества это довольно широко поддерживается, как в Delphi (редактор библиотеки типов имеет все необходимое и обновляет ваш код, а com internals и регистрация обслуживаются из ComServ unit), и за пределами Delphi (я использую его в ряде проектов для взаимодействия со всеми видами приложений: проектами c++, документами Word и Excel с использованием VBA, oldskool ASP...).
единственным недостатком, с которым я столкнулся, могут быть проблемы с потоками, в обычных приложениях, простой CoInitialize(nil); при запуске приложения будет делать, в более сложных приложениях, вам нужно подумать о "threading apartments" или использовать бесплатную резьбу и сделать свою собственную блокировку. (Что в некоторых случаях вы делаете уже.)
Другой альтернативой, которая проста в реализации, является использование базы данных для передачи информации.
Не слишком элегантный, и он использует много накладных расходов, но если ваше приложение уже известно о данных (т. е. имеет базу данных как ее часть), то использование таблицы или двух для передачи информации довольно легко.
вы можете использовать простые файлы: одна сторона пишет, другая читает. Если вам нужна двусторонняя связь, просто используйте два файла, по одному для каждого направления.
конечно, это не очень высокая производительность.
еще один голос от меня за именованные каналы, за обмен данными. Мне они нравятся немного больше, чем файлы mmap, так как API-интерфейсы win32 pipe дают вам хороший выбор из коробки: sync/async, Byte stream vs message packets, простые вызовы ReadFile/WriteFile. Все что вы может сделайте себя с mmaps... но трубы уже есть...
и вы можете управлять доступом с атрибутами безопасности , что не является опцией с WM_CopyData. Это не может быть проблемой немедленно... но может быть удобно иметь возможность, даже если вам все равно, кто отправляет ваши сообщения приложения. Для меня это было полезно, когда Vista появилась, и внезапно пользовательские приложения побежали в отдельном сеансе к моей службе. Было хорошо, что настройка атрибутов безопасности была единственной вещью, необходимой, чтобы заставить вещи работать снова.
для "инициирования действий" вы можете уйти с чем-то таким же простым, как некоторые именованные события, и не беспокоиться о отправке сообщений вообще? Заинтересованные партии просто ждут сигнала.
лично я бы избегал COM, Если вам не нужно специально поддерживать COM-клиентов.
Не используйте COM, слишком много накладных расходов (варианты), и вы должны зарегистрировать вас .dll или .exe (и это дает много странных проблем с установкой + обновлением).
Я должен пойти на MMF, я использую это для связи со службами Windows. Для этого я использую следующий TGpMessageQueueReader и writer: http://17slon.com/gp/gp/gpsync.htm
Если вы хотите передать данные, функции вызова и т. д., Используйте COM, однако, если есть много вызовов, знайте, что COM медленный. Кроме того, вам, возможно, придется зарегистрировать заявку с "xxx.exe / Regserver", прежде чем он будет работать.