Shulou(Shulou.com)06/02 Report--

This article mainly introduces how to design a managed interface for peer-to-peer message queues in .NET. It is very detailed and has a certain reference value. Interested friends must read it!

Design a managed interface for peer-to-peer message queues

Before designing a managed interface for any native API set, you first need to see if it has been implemented. For peer-to-peer message queues, there is no ready library and the search results provide only a small amount of information about the API description. Since there has been little involvement in this area before, it seems worthwhile to describe the design and implementation of a managed wrapper for peer-to-peer messaging API.

When developers wrap a set of related Win32 API into one or more managed classes, they use a common pattern; most Windows API manipulate a handle (and treat it as their * parameters). From an object-oriented point of view, this handle can be thought of as an object identity. You can group all methods related to handles into classes that expose the same methods. Except that the handle is not required, these methods have the same signature as the original method. This handle is obtained when the object is created and closed when the object is disposed of / destructed. In .NET Compact Framework, handles are represented by the IntPtr type. Therefore, based on the previous information, you can create a class that wraps a specific native API as follows.

+ 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 ()

The five methods in the above code example can form the main interface, but also define MsgQueueOptions and any other structures in managed code (as the unmanaged structures used in platform calls do). This interface is a good start and provides you with a wrapper, but it is not entirely object-oriented and does not apply to the rest of the .NET Compact Framework, and it places a significant additional burden on the client (in terms of the code to be written). The interface can still be improved.

This should be done wherever method overloading is introduced to simplify the methods that client code must handle. For example, if you need to create an unnamed queue, the client does not have to pass in NULL-further, the name parameter should not be in the constructor. If you need to read or write columns in a blocking manner instead of passing INFINITE (- 1) as a timeout parameter, you don't have to pass anything. Applying these changes will increase the number of methods in the class and will make it easier to use in simpler scenarios without limiting more complex situations.

The interface can be further improved. Note that you need to pass a byte array and the size of the ancestor; passing the size of the array is not necessary because the size of a given array can be determined at any time. Unless the array length is explicitly required in the signature (for example, for performance reasons, because caching the size is faster than recalculating it each time), you can delete the bufSize parameter. In fact, the byte array parameter (buf) can be encapsulated in its own type / class along with the flags parameter, which indicates whether the information is a warning message.

Another way to make API more object-oriented is to eliminate the structure-which makes sense. For example, instead of setting the structure and passing it to the constructor, you can inline the structure element as a parameter with the appropriate overload (in other words, you can turn the structure member into a series of parameters). Rather than returning a structure with queue information, a better solution is to inline the structure field to the read-only property on the class itself.

You should be able to recall two facts in the * * section of this article: like many other methods, the point-to-point message queuing API method returns BOOL to indicate success or failure, and the extended error message requires a separate call. You can use two non-exclusive methods to map this behavior (that is, returning a Boolean value and needing to retrieve extended error messages separately). The * method is to cause the application to throw an exception when an error occurs and make the exception with an extended error message. The second method is to have the application return an enumeration containing the possible results (including success) of the method call. As a general principle, developed applications should throw exceptions only if the condition cannot be recovered.

At this stage, it is useful to find similar classes in the .NET Framework, and you will certainly find MSMQ classes in System.Messaging (which is also available in .NET Compact Framework version 2.0). You can use the same naming convention used by members of this class (for example, change Read to Receive and Write to Send). Notice how the MSMQ class provides a Purge method for emptying messages in the queue. You can enhance your classes with this method; in other words, although native API does not provide methods, it does not mean that you cannot add a value to the wrapper by adding a method.

Because the OpenMsgQueue method returns a handle, and you have mapped the handle to a class, it makes sense for the wrapper method to return an instance of the wrapper class. In addition, the method does not require an existing state when executed, so you should make it static. *, you need to convert the structure to a single parameter you need: whether it is a read-only queue or a write-only queue.

This is all of the article "how to design a managed interface for peer-to-peer message queues in .NET". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.