Как лучше общаться между доменами приложений? - PullRequest
Новая
       14

Как лучше общаться между доменами приложений?

37 голосов
/ 24 ноября 2008

У меня есть приложение, которое должно отправлять умеренно большой объем сообщений между несколькими доменами приложений. Я знаю, что мог бы реализовать это с помощью удаленного взаимодействия, но я также заметил, что есть междоменные делегаты. Кто-нибудь смотрел на такую ​​проблему?

Ответы [ 6 ]

26 голосов
/ 24 ноября 2008

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

EDIT: См. здесь для получения более подробной информации, включая ссылку на пример реализации.

12 голосов
/ 24 ноября 2008

Междоменный делегат допускает только метод void с нулевыми параметрами, и это, вероятно, не то, что вы думаете. Он едва полезен в качестве простого обратного вызова для уведомления от одного домена приложения к другому, например, такой метод, как InitComplete () или что-то.

Remoting - ЕДИНСТВЕННЫЙ выбор, называете ли вы его WCF или как-то еще, передавая сериализуемые типы или используя типы MBRO (MarshalByRefObjects). Это не так сложно, как вы думаете.

-Oisin

10 голосов
/ 17 июня 2012

Я только что обнаружил, что вы также можете использовать AppDomain.SetData, но это только один из способов От хост-домена к дочернему домену. 

static void RunInChildDomain()
{
     AppDomain childDomain = AppDomain.CreateDomain("friendlyName");
     string parameterValue = "notmii";
     childDomain.SetData("parameter", parameterValue);
     childDomain.DoCallBack(PrintName);
}

static void PrintName()
{
     string Name = Convert.ToString(AppDomain.CurrentDomain.GetData("parameter"));
     Console.WriteLine(Name);
}

Вы также можете создать управляемую исключениями связь между дочерним и хост-доменом приложения с помощью события AppDomain.FirstChanceException:)

3 голосов
/ 24 ноября 2008

Это просто мысль, но я слышал, что даже для междоменной связи WCF будет рекомендуемым подходом, начиная с .NET 3.0, конечно. На самом деле это имеет смысл, поскольку удаленное взаимодействие - это просто еще одна технология, обернутая WCF.

2 голосов
/ 01 августа 2018

CallContext позволяет передавать данные между доменами приложений: 

   CallContext.LogicalSetData("Key", "My value");
   Console.WriteLine("{0} from {1}", CallContext.LogicalGetData("Key"),               
   AppDomain.CurrentDomain.FriendlyName);

   var appDomain = AppDomain.CreateDomain("Worker");
   appDomain.DoCallBack(() => Console.WriteLine("{0} from {1}", 
       CallContext.LogicalGetData("Key"), 
       AppDomain.CurrentDomain.FriendlyName));
   AppDomain.Unload(appDomain);

   CallContext.FreeNamedDataSlot("Key");

Код использует System.Runtime.Remoting.Messaging. Я лично не измерял производительность этого решения.

2 голосов
/ 09 июня 2016

Я хочу расширить ответ xOn. Он рекомендует использовать либо WCF, либо MarshalByRefObject, но, учитывая, что вопрос касается связи между доменами приложений, а не связи между процессами, я думаю, что подход MBRO значительно проще в реализации и, следовательно, правильный ответ.

Когда я сам исследовал эту проблему, я сначала пытался понять, как дочерний домен AppDomain мог общаться с родителем, пока не понял, что вы можете передать дескриптор объекта MBRO в дочерний объект, а потом ребенок может развернуть его. этот дескриптор для связи с родителем (или любым другим AppDomain). Я отправил решение моего собственного вопроса здесь .

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

...