为点对点消息队列设计托管接口

开发 后端
本文介绍了为点对点消息队列设计托管接口时需要考虑的方面。

为点对点消息队列设计托管接口

在为任何本机 API 集设计托管接口之前,首先需要查看它是否已经实现了。对于点对点消息队列,没有现成的库且搜索结果只提供有关 API 描述的少量信息。由于之前很少涉足该领域,因此描述针对点对点消息 API 的托管包装的设计和实现看起来是值得的。

当开发人员将一组相关 Win32 API 包装到一个或多个托管类中时,会使用一个通用模式;大多数 Windows API 都操作一个句柄(并将其视为它们的***个参数)。从面向对象的角度看,可将该句柄看作对象标识。您可以将与句柄相关的所有方法分组到公开相同方法的类中。除不需要该句柄之外,这些方法拥有与原始方法相同的签名。该句柄在对象创建时获取,在对象处置/析构时关闭。在 .NET Compact Framework 中,句柄由 IntPtr 类型表示。因此,根据前面的信息,您可以按以下方式创建包装特定本机 API 的类。
+ constructor(String name, MsgQueueOptions opt)
+ ReadMsgQueue(byte[] buf, Int32 bufSize, Int32 numRead, Int32 timeout, Int32 flags)
+ WriteMsgQueue(byte[] buf, Int32 bufSize, Int32 timeout, Int32 flags)
+ GetMsgQueueInfo(MsgQueueInfo info)
+ Close()

上述代码示例中的五个方法可以形成主接口,但是还要用托管代码定义 MsgQueueOptions 和任何其他结构(如同在平台调用中使用的非托管结构所做的那样)。该接口是一个不错的开端并为您提供了一个包装,但它并不是完全面向对象的并且不适用于 .NET Compact Framework 的其他部分,而且它给客户端带来了较大的额外负担(就要编写的代码而言)。该接口仍然可以改进。

无论在何处引入方法的重载都应该这样做,以便简化客户端代码必须处理的方法。例如,如果需要创建一个无名队列,则客户端不一定要传入 NULL — 进一步说,name 参数不应该在构造函数中。如果需要以阻塞方式读取或写入对列,而不是将 INFINITE (-1) 作为 timeout 参数进行传递,则不一定要传递任何内容。应用这些更改将增加类中的方法数量,而且将使它更易于在较简单的方案中使用,同时不会限制更复杂的情况。

该接口可以进一步改进。注意,需要传递字节数组以及该数祖的大小的方式;传递数组大小不是必要的,因为可在任何时间确定给定数组的大小。除非在签名中显式需要数组长度(例如,出于性能原因的考虑,因为缓存该大小比每次重新计算它要快),否则可以删除 bufSize 参数。实际上,可将字节数组参数 (buf) 与 flags 参数(它指明该信息是否为一个警告信息)一起封装到它自己的类型/类之中。

另一个使 API 更加面向对象的方法是消除结构 — 这很有意义。例如,您不必设置结构并将其传递给构造函数,而是可以将结构元素作为参数与适当的重载内联(换言之,可以使结构成员变为一系列参数)。与返回带有队列信息的结构相比,更好的解决方案是将结构字段内联到类本身上的只读属性。

您应该能回想起本文***部分中的两个事实:与其他许多方法一样,点对点消息队列 API 方法返回 BOOL 来指示成功或失败,而且扩展的错误信息需要一个单独的调用。可以使用两个非独占方法来映射该行为(即,返回布尔值以及需要单独检索扩展的错误信息)。***个方法是使应用程序在发生错误时引发一个异常,并使该异常带有扩展的错误信息。第二个方法是使应用程序返回包含该方法调用的可能结果(包括成功)的枚举。作为一个通用原则,开发的应用程序应该仅在状况无法恢复时才引发异常。

在该阶段,在 .NET Framework 中查找相似类是很有用的,并且您肯定能在 System.Messaging(在 .NET Compact Framework 版本 2.0 中也可用)中找到 MSMQ 类。您可以采用该类的成员所使用的相同命名约定(例如,将 Read 更改为 Receive,并将 Write 更改为 Send)。注意,MSMQ 类如何提供一个用于清空队列中消息的 Purge 方法。您可以通过该方法增强自己的类;换言之,虽然本机 API 不提供方法,但这并不意味着您无法通过添加一个方法来向包装添加值。

由于 OpenMsgQueue 方法返回一个句柄,并且您已将该句柄映射到一个类,因此包装方法返回包装类的实例是很有意义的。此外,该方法在执行时不需要现有状态,因此您应该使它成为静态的。***,需要将该结构转化为所需的单个参数:它是只读队列还是只写队列。

请注意,这里不描述平台 invoke 声明。

以上就介绍了为点对点消息队列设计托管接口时需要考虑的方面。

【编辑推荐】

  1. 点对点消息队列函数:用于WinCE的IPC机制
  2. ASP.NET中无Cookie会话的优点与缺点
  3. 无Cookie会话的实现
  4. ASP.NET Cookie:不是问题的问题
  5. .NET框架中的XML:XmlSerializer的内部原理
责任编辑:yangsai 来源: MSDN
相关推荐

2009-08-06 16:17:05

点对点消息队列

2017-10-11 15:08:28

消息队列常见

2021-05-31 08:00:00

消息队列架构Rabbit MQ

2024-10-16 15:11:58

消息队列系统设计

2017-04-27 10:07:52

框架设计实现

2019-10-22 08:12:49

消息队列分布式系统

2010-04-21 12:39:48

Unix 消息队列

2017-02-27 14:25:50

Java队列Web

2022-04-12 11:15:31

Redis消息队列数据库

2009-12-07 09:23:05

2009-11-09 16:57:05

WCF托管特性

2012-09-24 11:48:05

IBMdw

2010-04-21 12:12:56

Unix 消息队列

2010-04-13 17:00:43

Unix消息队列

2021-02-19 09:19:11

消息队列场景

2009-11-09 11:15:06

WCF消息队列

2021-03-11 06:01:41

Linux消息队列

2010-01-19 11:38:02

世纪互联

2022-12-13 09:19:26

分布式消息队列

2023-12-18 08:36:39

消息队列微服务开发
点赞
收藏

51CTO技术栈公众号