Version imprimable
Bonjour,
J'aurais aimé savoir si il existait un autre moyen de communication des données que le .Net Remoting ou les Web Services ? Et aussi avoir le retour d'expérience sur le .Net Remoting d'utilisateurs si possible. J'ai besoin de ces infos pour déterminer un potentiel changement d'architecture d'une appli.
Merci
Je n'utilise plus que WCF (Windows Communication Foundation). C'est une technologie très simple à mettre en place qui permet de ne pas changer le code que tu fasses du http, tcp, pipe, ...
.NET Remoting est une technologie plutôt ancienne qui était un prémice à WCF.
depuis l'avènement du framework 3.0, on a vu l'arrivée de WCF qui s'est pas mal étoffé avec le framework 3.5+/SP1.
WCF est une couche de communication unifiée qui avec les mêmes écritures ultra simplifiée permet de recourir à toutes ses anciennes techno et de nouvelles.
Donc .NET Remoting ne devrait plus être envisagé aujourd'hui sauf pour un développement spécifiquement en dotnet 2.0.
note au passage qu'il est possible de faire cohabiter un tiers en .NET Remoting et l'autre tiers écrit en WCF, ca communique très bien.
j'ai utilisé cette particularité pour un développement de la société quand je suis arrivé, le serveur est écrit en WCF, le client obligatoirement en dotnet 2.0 lui est écrit en .NET Remoting.
Quand aux webservices, et bien .NET Remoting pour peu que tu utilise des canaux Http, ou des Endpoint et un binding wsHTTP en WCF, utilisent SOAP sauf indication contraire, donc totalement compatible avec les webservices, donc plus aucun intérêt à les utiliser explicitement de nos jours.
C'est vrai qu'à l'époque de dotnet 3.0 et 3.5 WCF était nettement plus lent que NET Remoting, c'est pourquoi il vallait mieux mixer et écrire un tiers en WCF et l'autre en Remoting, mais ce pêché de jeunesse de WCF a été corrigé discrètement avec le SP1 de dotnet 3.5 et je crois même quelques KB précédentes.
.NET remoting ne gère pas les sessions sur les protocoles HTTP, et nécessite donc de faire sa propre soupe.
De plus, les classes qui implémentent les interfaces côté serveur doivent impérativement hériter de MarshalByRefObject ce qui rend les respects des règles fondamentales du développement difficile, surtout si ton "service" doit hériter d'autres classes spécifiques.
WCF permet un découpage complet, et permet de ne pas hériter les classes qui implante les interfaces, de même il est possible de décrire simplement des classes de données qui vont transiter par le service, si elles sont un peu exotiques, et les classes simples peuvent être transmises à même sans déclaration spécifique par les attributs.
L'utilisation des attributs rend l'utilisation de WCF plus claire, plus rapide, inutile de mettre du code spécifique.
Si tu veux plus de détails, je peux toujours t'en donner par MP.
Tu trouvera plus facilement des documents et tutoriels pour utiliser WCF de nos jours que .NET Remoting. La grande majorité des bon ouvrages de références pour .NET Remoting sont surtout en anglais, alors que pour WCF, on trouve de tout en francais :)
Et bien merci à vous deux, j'ai eu ma réponse :)
@mezian : Je n'ai aucun format spécifique de transfert de données pour le moment dans l'existant ^^ Je ne communique que par des requêtes injectées à l'aide de chaîne de caractères. C'est génial, n'est-ce pas...
@Cine : Merci pour les informations, si jamais j'ai un gros doute sur un truc je te demanderais conseil ;) (Mais sans en abuser bien entendu ^^, il faudra vraiment que je sois largué)