.NET a une chose appelée le remoting où vous pouvez passer des objets entre des domaines d'applications séparés ou même entre des machines physiques. Je ne comprends pas entièrement comment la magie opère, d'où cette question.
Dans le remoting, il existe deux façons principales de passer des objets - soit ils peuvent être sérialisés (convertis en une série d'octets puis reconstruits à l'autre extrémité) soit ils peuvent hériter de MarshalByRefObject, auquel cas .NET crée des proxies transparents et toutes les appels de méthodes sont renvoyés à l'instance d'origine.
C'est plutôt cool et cela fonctionne comme par magie. Et je n'aime pas la magie en programmation. En regardant le MarshalByRefObject
avec Reflector, je ne vois rien qui le distingue d'un objet typique. Même pas un attribut interne étrange ou quoi que ce soit. Alors comment tout le système de proxy transparent est-il organisé ? Puis-je créer un tel mécanisme moi-même ? Puis-je créer une alternative MyMarshalByRefObject
qui n'hériterait pas de MarshalByRefObject
mais agirait tout de même de la même manière ? Ou bien MarshalByRefObject
reçoit-il un traitement spécial de la part du moteur .NET lui-même et tout l'exploit du remoting est-il non duplicable par de simples mortels ?
1 votes
Si .NET Remoting traite toutes les classes qui héritent de MarshalByRefObject de manière spéciale, cela qualifie-t-il "MarshalByRefObject est spécial"? Utilisez Reflector sur .NET Remoting et trouvez la magie. Au fait, .NET Remoting est obsolète, tout comme MarshalByRefObject. Il peut bien sûr être utilisé, mais WCF est actuellement l'architecture de "remoting" prédominante dans .NET.
1 votes
WCF prend toujours en charge MarshalByRefObject
8 votes
La magie réside dans le jitter, il traite les classes MBRO de manière spéciale. Il n'accède plus directement aux champs d'une classe, mais génère du code pour utiliser une méthode d'aide CLR à la place. Ce qui sait que l'objet est distant et sait quand générer un appel de proxy.