是否可以通过一些其他配置来实现？
Publish / Send方法。在这种情况下，如果我在消息界面中进行了某些更改（例如，重命名属性），则不会收到编译时错误。为什么推荐这个？如何处理匿名对象的脆弱性？
谢谢！
答案 0 :(得分：4)
首选消息接口的建议基于“共享模式，而不是类型”原则。接口是合同，可以共享合同。您提到自己“避免共享消息_classes”。这是因为类也具有行为，并且许多项目都受到包含行为的消息类的困扰，这可能会阻止反序列化，并给消息引入特定于域的关注，实际上，这些仅是属性包。
文档明确指出：
强烈建议使用接口进行消息合同， 基于几年的经验，不同水平的 开发人员经验。
，尽管这一建议很强烈，但不能视为一项要求。如果组织中的所有开发人员都清楚消息是属性包的概念，并且只包含具有原始类型的属性，并且最多包含具有原始类型的属性类型的复杂类型，则可以选择使用类而不是接口。
没有建议甚至没有建议使用匿名类型。这是可能的，但仅此而已。您可以完美地使用在消息生产者端实现消息接口的类，然后将无法随意分配该接口中不存在的属性。
您只与使用者共享接口，并且由于接口是只读接口，因此您不会遇到反序列化错误的问题，因为某些设置程序具有一些奇怪的代码，一个开发人员认为这些代码对于消息类型很有用。
在我们的实践中，我们使用接口，但从未使用匿名对象。我们还广泛使用POCO作为消息，因为开发人员拥有足够的经验并了解消息传递的工作原理。
关于共享的最后一件事是，我们不再使用nuget包共享消息契约。尽管它看起来很有吸引力且安全，但它在我们的日常工作中还是有一些障碍。我们更喜欢复制消息类（或接口）而不是使用源包。如果团队遵循版本控制和弱模式等良好做法，则不会产生任何问题。您唯一需要注意的就是保持名称空间完整。