Vla*_*nko 5 masstransit message-queue
可以通过一些额外的配置来实现这一点吗？
Publish/Send方法。在这种情况下，如果我更改消息界面中的某些内容（例如，重命名属性），则不会出现编译时错误。为什么推荐这个？如何处理匿名对象的脆弱性？
谢谢！
The suggestion to prefer message interfaces is based on the principle "share schema, not type". An interface is a contract and contracts are ok to share. You mentioned yourself "avoid sharing message _classes". That's because classes also have behaviour and many projects suffered from message classes that included behavour, which could prevent deserialisation and introduce domain-specific concern to messages, which, in fact, are nothing more than property bags.
The documentation clearly states:
It is strongly suggested to use interfaces for message contracts, based on experience over several years with varying levels of developer experience.
and this suggestion, although strong, cannot be seen as a requirement. If all developers in your organisation clearly understand the concept of messages being property bags and only contain properties with primitive types and, at max, complex types that are property bags with primitive types - you can choose to work with classes instead of interfaces.
There's no recommendation or even a suggestion to use anonymous types. It is a possibility, but no more than that. You can perfectly use classes that implement message interfaces on the message producer side and then you won't be able to arbitrarily assign properties that don't exist in the interface.
You only share interfaces with your consumers, and since interfaces are read-only, you don't have an issue with getting deserialisation errors because some setters have some weird code that one developer thought is useful for the message type.
In our practice, we used interfaces but never used anonymous objects. We also widely use POCOs as messages, since developers got enough experience and understanding how messaging works.
关于共享的最后一件事是我们摆脱了使用 nuget 包共享消息合约的做法。虽然它看起来有吸引力和安全，但它在我们的日常工作中造成了一些障碍。我们更喜欢复制消息类（或接口）而不是使用源包。如果团队遵循版本控制和弱模式等良好实践，则不会产生任何问题。您唯一需要注意的是保持命名空间完好无损。