Microsoft.ServiceBus.Messaging对Microsoft.Azure.ServiceBus

Question

MS最近引入了Microsoft.Azure.ServiceBus命名空间。

https://github.com/Azure/azure-service-bus/blob/master/samples/readme.md

它适合于新的.net标准框架(好像MS没有足够的半冗余代码库)。

我的问题是，在表现方面还能有多好呢？

我可以自信地说，Microsoft.ServiceBus.Messaging留下了很多不尽如人意的地方，特别是在持续接收方面。

Microsoft.ServiceBus.Messaging的一个非常有用的特性是建立在OnMessage()方法之上的消息泵。

新库没有这样的功能，需要重新绑定每个收据上的事件处理程序以保持抽水。绝对是倒退了一步。

寻求任何对两者都有经验并能进行比较的人的反馈。

Answer 1

为了解决您的问题，.netstd库提供了.netframework one中没有提供的内容：

1. 开放源码。新图书馆是完全开放的。您可以浏览，进入(与下一个版本)，而不设置符号服务器，贡献，并简单地审查事情如何运作。
2. 与.netframework库相比，新库是真正的异步库。
3. 减少责任和代码大小。例如，Message对BrokeredMessage。您的数据不再由客户端序列化。
4. 默认情况下AMQP，而不是SBMP。
5. 新客户端以.NET标准与完整框架为目标。
6. 某些客户端方面重新设计以提供更好的选项(OnMessage API用于提供更多的失败上下文，插件和扩展性、接口用于更容易的测试)。
7. 充分测试。

就性能而言，如果不是更好的话，它应该与老客户一样。

Microsoft.ServiceBus.Messaging的一个非常有用的特性是建立在OnMessage()方法之上的消息泵。

您仍然拥有OnMessage API，尽管重命名为RegisterMessageHandler。