成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

為點對點消息隊列設計托管接口

開發 后端
本文介紹了為點對點消息隊列設計托管接口時需要考慮的方面。

為點對點消息隊列設計托管接口

在為任何本機 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

框架設計實現

2009-11-09 16:57:05

WCF托管特性

2019-10-22 08:12:49

消息隊列分布式系統

2017-02-27 14:25:50

Java隊列Web

2010-04-21 12:39:48

Unix 消息隊列

2009-12-07 09:23:05

2022-04-12 11:15:31

Redis消息隊列數據庫

2021-02-19 09:19:11

消息隊列場景

2009-11-09 11:15:06

WCF消息隊列

2010-04-13 17:00:43

Unix消息隊列

2010-04-21 12:12:56

Unix 消息隊列

2012-09-24 11:48:05

IBMdw

2025-04-09 08:20:00

RocketMQ消息隊列開發

2010-01-19 11:38:02

世紀互聯

2021-03-11 06:01:41

Linux消息隊列

2010-04-21 14:39:59

Unix消息隊列
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久国 | 特黄一级| www.久久99 | 日韩欧美在线视频 | 亚洲永久入口 | 精品国产乱码久久久久久蜜退臀 | 国产精品一区视频 | 色婷婷综合久久久中字幕精品久久 | 欧美日韩免费视频 | 91精品国产高清久久久久久久久 | 亚洲一区二区三区在线 | 亚洲视频一区在线观看 | 成人免费视频 | 中文字幕电影在线观看 | www.日韩 | 久久伊人操 | 免费视频二区 | 欧美日韩精品一区二区三区四区 | 日韩精品在线观看网站 | zzzwww在线看片免费 | 国产探花在线精品一区二区 | 日韩一区二区三区视频 | 国产日韩久久 | 日韩在线中文字幕 | 伦理一区二区 | 久久久久国产 | 国产91九色 | 精品美女久久久 | 久久伊人青青草 | 国产夜恋视频在线观看 | 久久这里只有精品首页 | 久久久久国产精品一区 | 欧美精品一区二区在线观看 | 免费观看毛片 | 日本精品视频 | 久久精品在线免费视频 | 一区二区三区四区在线视频 | 人人天天操 | 日本手机在线 | 欧美视频在线观看 | 人人亚洲|