Что лучше всего подходит для межпроцессного взаимодействия .NET?

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

Если вы имеете в виду межпроцессное взаимодействие, я до сих пор без проблем использовал .NET Remoting. Если два процесса находятся на одном компьютере, обмен данными происходит довольно быстро.

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

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

Удаленное взаимодействие .Net не является протоколом сам по себе. Он позволяет вам выбрать, какой протокол использовать: SOAP, именованные каналы и т. д.

WCF - лучший выбор. Он поддерживает ряд различных транспортных механизмов (включаяИменованныйТрубы) и может полностью управляться конфигурацией. Я очень рекомендую вам взглянуть на WCF.

Вот блог, который делает Сравнение производительности WCF и удаленного взаимодействия.

Цитата из блога:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting. If I would start completely new project I would chose the WCF. Anyway the WCF does much more than Remoting and for all those features I love it.

Раздел MSDN для WCF

Удаленное взаимодействие в .NET Framework 2.0 предоставляет Канал IPC для межпроцессного взаимодействия на одном компьютере.

Если вы используете .NET Framework 3.0 или выше, я бы использовал WCF. Используя WCF, вы можете использовать разные привязки в зависимости от компромисса между производительностью / взаимодействием и т. д. что вам нужно.

Если производительность не критична и вам необходимо взаимодействие с другими технологиями веб-служб, вы захотите использовать привязку WS-HTTP. В вашем случае вы можете использовать WCF либо с привязкой net-tcp, либо с привязкой именованного канала. Либо должно работать.

Лично я считаю, что подход WCF более чистый, поскольку вы можете создавать сервисы, управляемые контрактами, и сосредотачиваться на сообщениях, а не на объектах (здесь я делаю обобщение на основе моделей программирования WCF / .NET Remoting по умолчанию). Мне не нравится пересылать объекты по сети, потому что много семантической информации теряется или непонятно. Когда все, что вы делаете, это отправляет сообщение, как в случае с WCF, становится легче разделить ваши проблемы между коммуникацией и классами / инфраструктурой, из которых состоит один узел.

WCF также обеспечивает гибкость. Просто изменив некоторую конфигурацию (привязку), вы можете использовать ту же службу на другом компьютере вместо IPC на том же компьютере. Поэтому ваш код остается гибким.