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

在为任何本机 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的内部原理