Comment puis-je partager des classes de message entre applications lorsque vous utilisez NServiceBus?

Question

J'ai donc deux applications séparées entre lesquelles je veux envoyer des messages. J'utilise NServiceBus, mais cela ne devrait pas vraiment avoir d'importance. Comment puis-je envoyer un message de l'application A à l'application B et les faire connaître au même contrat?

Alors app A a une SecretMessage classe ...

public class SecretMessage : IMessage 
{ 
    public string Title { get; set; } 
    public string Body { get; set; } 
} 

Tel est l'objet qui sera publié en feuilleton et envoyé sur le fil à l'application B.

maintenant dans l'application B, comment puis-je écouter les messages qui sont de ce type et ensuite être en mesure de les désériver en série à la même classe? Je peux donc utiliser les données telles qu'elles ont été envoyées, sans que cela ne soit un cauchemar de maintenance.

L'application B doit-elle simplement avoir une copie de la classe? Est-ce que ceci devrait être traité par une DLL partagée de classes de message auxquelles chaque application fait référence (j'espère que non)? Devraient-ils être recréés dans chaque application en tant que DTO complètement séparés avec les mêmes propriétés?

Ai-je raté quelque chose ici?

Answer 1

Ce n'est peut-être pas la réponse que vous voulez, mais il y a très peu de balles d'argent ici.

Vous avez vraiment seulement eu quelques choix, et comme tel dépend alors du niveau de fonctionnalité et de type durcissement que vous voulez dans vos classes de messages:

1. DLL partagés - avantages qu'il peut être un code + structure par exemple constructeurs utiles, énumérateurs complexes, débogage des implémentations ToString, etc. Nécessite un projet séparé et une distribution pour DLL.
2. Schéma partagé et génération de code. Déclarez le schéma pour vos types et utilisez la génération de code pour créer des classes. Beaucoup de différentes stratégies ici - quelques exemples: T4 Templating, Custom Code Generation, des outils et des bibliothèques telles que CodeSmith ou Proto.Bufs. La recherche vous trouvera plus de charges. Peut être assez puissant - connaître de nombreux codeshops qui démarrent tous les projets grâce au prototypage rapide avec CodeGen de la base de données jusqu'à l'interface utilisateur. Vous devez toujours distribuer le schéma.
3. Sérialisation d'un message avec suffisamment de fidélité pour générer des types via Code DOM. Chaque message implique le coût de transporter suffisamment de métadonnées de type pour être représentatif de toutes ses instances de message. par exemple. représentations de champs nullables. Il y aurait également un coût de «découverte» intrinsèque pour la première fois afin de générer les types de wrapper de message.
4. Sérialiser des données dans une structure faible, telle que des paires nom/valeur, puis générer des classes wrapper de type dictionnaire. Typage faible - facile à étendre.

Ce sont vraiment les seuls choix. IMHO # 2 puis # 1 dans cet ordre sont généralement les modèles les plus utiles.

Answer 2

Comme suggéré par Juval Lowy in Programming .NET Components, séparer les interfaces pures dans leur propre DLL partagée.

http://arcanecode.com/2007/02/14/more-oop-interfaces-in-c-part-2/