我需要将一个VB 6.0应用程序迁移到VB.Net（Framework 3.5）。该应用程序大量使用MSMQ。我正在尝试弄清楚使用WCF相比于System.Messaging有什么优势。使用System.Messaging是否存在任何潜在问题？
5个回答
7
我认为来自“Motley Queue”网站（“web”：出色的链接！）的这句话最能概括：
*WCF编程模型以您的业务操作为中心。有了它，您可以停止管理消息事务、设置消息属性、在队列中搜索消息、检查NACKS、重试消息等。相反，您可以开始从业务操作（例如CreatePurchaseOrder）的角度思考世界，并专注于业务逻辑。 让WCF处理繁琐的细节。 *
这就是WCF试图实现的 - 为您减轻大量的管道和复杂性，让您集中精力解决想要解决的业务问题。
我的投票是给WCF的！ :-)
Marc
- marc_s
3
我有点不同意WCF比System.Messaging更容易/更干净，因为System.Messaging有一个相当简单的API（整体而言），如果您只关心它，那么使用起来相对简单。但是，WCF确实有一些好东西，但它绝不简单。
至于您是否会遇到任何问题，这取决于您的VB应用程序当前如何使用MSMQ以及发送哪种类型的数据。您将使用MsmqIntegrationBinding绑定，这有所帮助，但如果您的VB应用程序不以WCF可以直接处理的格式发送消息，则可能需要使用一些技巧来成功处理消息反序列化。
- tomasr
2
我个人非常喜欢MSMQ，会选择它。
对我来说，主要的问题是每条消息的限制为4兆字节。如果你要序列化一个大的对象图，则会出现问题，但只需先将其序列化到磁盘上，然后发送文件名即可轻松解决。
正如其他帖子中的评论所述，MSMQ可能不会获得“新功能”，但在我看来，它很稳定，非常可扩展，并且已经具备了我需要的所有功能。
- Noon Silk
1
选择使用 WCF，将为您提供一个明确的前进路径。虽然我怀疑 System.Messaging 并不会消失（请参见 System.Runtime.Remoting），但是新的开发将会在 WCF 上进行，这也使得您可以迁移到其他技术上。它使您摆脱了被绑定到特定传输实现的限制。
WCF 编程模型也非常干净和令人愉悦。
- Mark
2
1我查看了MSDN上的System.Runtime.Remoting摘要，但是我没有看到关于System.Messaging的参考。你能否更具体地说明你希望我们在Remoting中看到什么？ - user456814
System.Messaging并不会消失，就像System.Remoting一样。它们都是相当根深蒂固的技术，因此在它们消失之前会有足够的警告。 - Mark
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接