Quel est le meilleur choix pour la communication inter-processus .NET?

WCF est le meilleur choix. Il prend en charge un certain nombre de mécanismes de transport ( y compris Named Pipes ) et peut être entièrement piloté par configuration. Je vous recommande fortement de jeter un coup d’œil à WCF.

Voici un blog qui effectue une comparaison des performances entre WCF et Remoting .

Une citation du blog:

WCF et .NET Remoting sont vraiment comparables en termes de performances. Les différences sont tellement faibles (mesure de la latence du client) que peu importe laquelle est la plus rapide. WCF a cependant un meilleur débit de serveur que .NET Remoting. Si je commençais un projet complètement nouveau, je choisirais la WCF. Quoi qu’il en soit, la WCF fait beaucoup plus que Remoting et pour toutes ces fonctionnalités, je l’aime.

Section MSDN pour WCF

Si c’est sur une seule machine, Named Pipes vous donne de meilleures performances et peut être implémenté avec l’ infrastructure à distance ainsi que WCF. Ou vous pouvez simplement utiliser directement System.IO.Pipes .

Si vous voulez dire communication inter-processus, j’ai utilisé .NET Remoting sans aucun problème jusqu’à présent. Si les deux processus sont sur la même machine, la communication est assez rapide.

Les tubes nommés sont nettement plus efficaces, mais ils nécessitent la conception d’au moins un protocole d’application de base, ce qui pourrait ne pas être réalisable. Remoting vous permet d’appeler facilement des méthodes distantes.

La communication à distance dans .NET Framework 2.0 fournit le canal IPC pour la communication entre processus au sein de la même machine.

Si vous utilisez le .NET Framework 3.0 ou supérieur, j’utiliserais WCF. En utilisant WCF, vous pouvez utiliser différentes liaisons en fonction du compromis entre performance / interop / etc. que vous avez besoin

Si les performances ne sont pas critiques et que vous devez interagir avec d’autres technologies de service Web, vous souhaiterez utiliser la liaison WS-HTTP. Dans votre cas, vous pouvez utiliser WCF avec une liaison net-tcp ou une liaison nommée. L’un ou l’autre devrait fonctionner.

Mon sharepoint vue personnel est que l’approche WCF est plus propre car vous pouvez effectuer des services sous contrat et vous concentrer sur les messages, pas sur les objects (je fais une généralisation basée sur les modèles de programmation par défaut de WCF / .NET Remoting). Je n’aime pas envoyer des objects à travers le câble car beaucoup d’informations sémantiques sont perdues ou ne sont pas claires. Lorsque tout ce que vous faites est d’envoyer un message comme vous le faites avec WCF, il devient plus facile de séparer vos préoccupations entre la communication et les classes / infrastructure dont un seul nœud est composé.

.Net Remoting n’est pas un protocole en soi. Il vous permet de choisir quel protocole utiliser: SOAP, pipes nommés, etc.

WCF offre également de la flexibilité. En changeant simplement certaines config (liaison), vous pouvez avoir le même service sur une autre machine au lieu d’IPC sur la même machine. Votre code rest donc flexible.

La communication à distance .net est intégrée à .net pour la communication de processus interne. Si vous l’utilisez, ils continueront à prendre en charge et éventuellement à l’améliorer dans les futures versions. Les canaux nommés ne vous donnent pas la promesse d’améliorations dans les futures versions de .net