2012-01-23 2 views
4

Мы создаем приложение (WinForms, .NET 3.5), которое загружает DLL-модули «Plugin» в дополнительный AppDomain. Вторичному AppDomain необходимо время от времени сообщать с 1-го (более конкретно, вызывать или получать данные из объектов, созданных в основном AppDomain).Связь между AppDomains

Я прочитал большую часть материала об AppDomains и общении между ними.

До сих пор только простое решение я видел было унаследовать от MarshalByRefObject и пропускание TransparentProxy в 2 AppDomain, вызывая методы на прокси-сервере.

Этот метод имеет свои недостатки (не всегда возможно наследовать от MBRO в случае, например, типов фреймов или типов, которые уже наследуются от другого класса, статических полей/классов и т. Д.).

Поскольку ток точек связи являются довольно постоянными (только 2-3 сценариями, которые требуют коммуникации), я рассмотрел создание простого Посредника класса со следующими свойствами:

  1. будет создан в 1-й (основной) AppDomain.
  2. Будет функционировать только как «прохожий» для «реальных» объектов, созданных в главном AppDomain.
  3. Наследуется от MBRO, а ссылка прокси-сервера будет отправлена ​​во второй AppDomain.

Вызов методов этого прокси-объекта, который, в свою очередь, вызовет методы на «реальных» объектах в 1-м AppDomain.

Мои вопросы -

  1. ли это, кажется логичным дизайном?
  2. Что еще более важно, существует ли уже класс посредников/сообщений, проходящих через WCF или любую другую инфраструктуру коммутации? это похоже на общую концепцию, и мне интересно, есть ли что-то подобное.
+0

Читая точку * Плагин * Я всегда спрашиваю сначала: «Вы когда-нибудь слышали о [MEF] (http://mef.codeplex.com/)?» – Oliver

+0

Да, я слышал об этом. AFAIK встроен в .NET, не уверен в поддержке более ранних версий ... Кроме того, я не уверен, как он подходит для этого конкретного сценария. –

+0

Я понимаю, что прошло 18 месяцев с момента публикации. Мне интересно, как вы разобрались.Мы сталкиваемся с аналогичными ограничениями, которые MEF сам по себе не может решить и что MAF, похоже, пошел по пути птицы-додо. –

ответ

5

Если вы не хотите, чтобы по какой-то причине не захотеть WCF, я бы предложил взглянуть на него. В частности, вы можете использовать NetNamedPipeBinding, который обеспечивает связь на одном компьютере с использованием именованных каналов. Вы можете найти более подробную информацию здесь: http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx

Как хорошо, здесь достаточно краткий blog entry demonstrating it's use (от WMP плагина к приложению третьих сторон).

Основываясь на вашем описании приложения, вы можете установить службу WCF в первом AppDomain, а затем вызвать эту службу из второго AppDomain.

+0

Спасибо, что посмотрю. Один вопрос: почему люди продвигают использование именованных труб разных транспортных сред? в чем его преимущества? –

+0

В контексте WCF связь по именованным каналам является механизмом, наиболее приспособленным для связи на отдельной машине. Фактически, вы не можете общаться через конечную точку с помощью NetNamedPipeBinding с другого компьютера. Альтернативные привязки, доступные в готовом виде, обычно более тяжелые с точки зрения протоколов (поэтому NetNamedPipedBinding, вероятно, будет более результативным), и как только вы начнете их использовать, вам нужно больше заботиться о безопасности (например, блокировка вниз, если вы используете NetTcpBinding). – remarkrm

+0

Ссылка на codenippet-managed-wmp-plugin-wcf-ipc сломана, знаете ли вы о другом? –