Должен ли я использовать именованные каналы или .NET Remoting для связи с запущенным процессом на моем компьютере?
Ответы:
WCF - лучший выбор. Он поддерживает ряд различных транспортных механизмов ( включая именованные каналы ) и может полностью управляться конфигурацией. Я очень рекомендую вам взглянуть на WCF.
Вот блог, в котором сравнивается производительность WCF и удаленного взаимодействия .
Цитата из блога:
WCF и .NET Remoting действительно сопоставимы по производительности. Различия настолько малы (измерение задержки клиента), что не имеет значения, какой из них немного быстрее. Хотя WCF имеет гораздо лучшую пропускную способность сервера, чем .NET Remoting. Если бы я начал совершенно новый проект, я бы выбрал WCF. В любом случае WCF делает гораздо больше, чем удаленное взаимодействие, и за все эти функции мне он нравится.
Если это на одном компьютере, именованные каналы обеспечивают лучшую производительность и могут быть реализованы с инфраструктурой удаленного взаимодействия, а также с WCF. Или вы можете просто использовать System.IO.Pipes напрямую .
Если вы имеете в виду межпроцессное взаимодействие, я до сих пор без проблем использовал .NET Remoting. Если два процесса находятся на одном компьютере, обмен данными происходит довольно быстро.
Именованные каналы определенно более эффективны, но они требуют разработки хотя бы базового протокола приложения, что может оказаться невозможным. Удаленное взаимодействие позволяет легко вызывать удаленные методы.
Если вы используете .NET Framework 3.0 или выше, я бы использовал WCF. Используя WCF, вы можете использовать разные привязки в зависимости от компромисса между производительностью / взаимодействием и т. Д. что вам нужно.
Если производительность не критична и вам необходимо взаимодействие с другими технологиями веб-служб, вы захотите использовать привязку WS-HTTP. В вашем случае вы можете использовать WCF либо с привязкой net-tcp, либо с привязкой именованного канала. Либо должно работать.
Лично я считаю, что подход WCF более чистый, поскольку вы можете создавать сервисы, управляемые контрактом, и сосредотачиваться на сообщениях, а не на объектах (здесь я делаю обобщение на основе моделей программирования WCF / .NET Remoting по умолчанию). Я не люблю пересылать объекты по сети, потому что много семантической информации теряется или неясно. Когда все, что вы делаете, - это отправка сообщения, как в случае с WCF, становится легче разделить ваши проблемы между коммуникацией и классами / инфраструктурой, из которых состоит один узел.
WCF также обеспечивает гибкость. Просто изменив некоторую конфигурацию (привязку), вы можете использовать ту же службу на другом компьютере вместо IPC на том же компьютере. Поэтому ваш код остается гибким.
Удаленное взаимодействие .Net не является протоколом сам по себе. Он позволяет вам выбрать, какой протокол использовать: SOAP, именованные каналы и т. Д.
Удаленное взаимодействие .net встроено в .net для внутреннего взаимодействия процессов. Если вы воспользуетесь этим, они продолжат поддерживать и, возможно, улучшат его в будущих версиях. Именованные каналы не обещают улучшений в будущих версиях .net