建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
為點(diǎn)對(duì)點(diǎn)消息隊(duì)列設(shè)計(jì)托管接口
10年積累的網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶(hù)對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶(hù)得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有綠園免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
在為任何本機(jī) API 集設(shè)計(jì)托管接口之前，首先需要查看它是否已經(jīng)實(shí)現(xiàn)了。對(duì)于點(diǎn)對(duì)點(diǎn)消息隊(duì)列，沒(méi)有現(xiàn)成的庫(kù)且搜索結(jié)果只提供有關(guān) API 描述的少量信息。由于之前很少涉足該領(lǐng)域，因此描述針對(duì)點(diǎn)對(duì)點(diǎn)消息 API 的托管包裝的設(shè)計(jì)和實(shí)現(xiàn)看起來(lái)是值得的。
當(dāng)開(kāi)發(fā)人員將一組相關(guān) Win32 API 包裝到一個(gè)或多個(gè)托管類(lèi)中時(shí)，會(huì)使用一個(gè)通用模式；大多數(shù) Windows API 都操作一個(gè)句柄（并將其視為它們的***個(gè)參數(shù)）。從面向?qū)ο蟮慕嵌瓤?，可將該句柄看作?duì)象標(biāo)識(shí)。您可以將與句柄相關(guān)的所有方法分組到公開(kāi)相同方法的類(lèi)中。除不需要該句柄之外，這些方法擁有與原始方法相同的簽名。該句柄在對(duì)象創(chuàng)建時(shí)獲取，在對(duì)象處置/析構(gòu)時(shí)關(guān)閉。在 .NET Compact Framework 中，句柄由 IntPtr 類(lèi)型表示。因此，根據(jù)前面的信息，您可以按以下方式創(chuàng)建包裝特定本機(jī) API 的類(lèi)。
+ 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()
上述代碼示例中的五個(gè)方法可以形成主接口，但是還要用托管代碼定義 MsgQueueOptions 和任何其他結(jié)構(gòu)（如同在平臺(tái)調(diào)用中使用的非托管結(jié)構(gòu)所做的那樣）。該接口是一個(gè)不錯(cuò)的開(kāi)端并為您提供了一個(gè)包裝，但它并不是完全面向?qū)ο蟮牟⑶也贿m用于 .NET Compact Framework 的其他部分，而且它給客戶(hù)端帶來(lái)了較大的額外負(fù)擔(dān)（就要編寫(xiě)的代碼而言）。該接口仍然可以改進(jìn)。
無(wú)論在何處引入方法的重載都應(yīng)該這樣做，以便簡(jiǎn)化客戶(hù)端代碼必須處理的方法。例如，如果需要?jiǎng)?chuàng)建一個(gè)無(wú)名隊(duì)列，則客戶(hù)端不一定要傳入 NULL — 進(jìn)一步說(shuō)，name 參數(shù)不應(yīng)該在構(gòu)造函數(shù)中。如果需要以阻塞方式讀取或?qū)懭雽?duì)列，而不是將 INFINITE (-1) 作為 timeout 參數(shù)進(jìn)行傳遞，則不一定要傳遞任何內(nèi)容。應(yīng)用這些更改將增加類(lèi)中的方法數(shù)量，而且將使它更易于在較簡(jiǎn)單的方案中使用，同時(shí)不會(huì)限制更復(fù)雜的情況。
該接口可以進(jìn)一步改進(jìn)。注意，需要傳遞字節(jié)數(shù)組以及該數(shù)祖的大小的方式；傳遞數(shù)組大小不是必要的，因?yàn)榭稍谌魏螘r(shí)間確定給定數(shù)組的大小。除非在簽名中顯式需要數(shù)組長(zhǎng)度（例如，出于性能原因的考慮，因?yàn)榫彺嬖摯笮”让看沃匦掠?jì)算它要快），否則可以刪除 bufSize 參數(shù)。實(shí)際上，可將字節(jié)數(shù)組參數(shù) (buf) 與 flags 參數(shù)（它指明該信息是否為一個(gè)警告信息）一起封裝到它自己的類(lèi)型/類(lèi)之中。
另一個(gè)使 API 更加面向?qū)ο蟮姆椒ㄊ窍Y(jié)構(gòu) — 這很有意義。例如，您不必設(shè)置結(jié)構(gòu)并將其傳遞給構(gòu)造函數(shù)，而是可以將結(jié)構(gòu)元素作為參數(shù)與適當(dāng)?shù)闹剌d內(nèi)聯(lián)（換言之，可以使結(jié)構(gòu)成員變?yōu)橐幌盗袇?shù)）。與返回帶有隊(duì)列信息的結(jié)構(gòu)相比，更好的解決方案是將結(jié)構(gòu)字段內(nèi)聯(lián)到類(lèi)本身上的只讀屬性。
您應(yīng)該能回想起本文***部分中的兩個(gè)事實(shí)：與其他許多方法一樣，點(diǎn)對(duì)點(diǎn)消息隊(duì)列 API 方法返回 BOOL 來(lái)指示成功或失敗，而且擴(kuò)展的錯(cuò)誤信息需要一個(gè)單獨(dú)的調(diào)用。可以使用兩個(gè)非獨(dú)占方法來(lái)映射該行為（即，返回布爾值以及需要單獨(dú)檢索擴(kuò)展的錯(cuò)誤信息）。***個(gè)方法是使應(yīng)用程序在發(fā)生錯(cuò)誤時(shí)引發(fā)一個(gè)異常，并使該異常帶有擴(kuò)展的錯(cuò)誤信息。第二個(gè)方法是使應(yīng)用程序返回包含該方法調(diào)用的可能結(jié)果（包括成功）的枚舉。作為一個(gè)通用原則，開(kāi)發(fā)的應(yīng)用程序應(yīng)該僅在狀況無(wú)法恢復(fù)時(shí)才引發(fā)異常。
在該階段，在 .NET Framework 中查找相似類(lèi)是很有用的，并且您肯定能在 System.Messaging（在 .NET Compact Framework 版本 2.0 中也可用）中找到 MSMQ 類(lèi)。您可以采用該類(lèi)的成員所使用的相同命名約定（例如，將 Read 更改為 Receive，并將 Write 更改為 Send）。注意，MSMQ 類(lèi)如何提供一個(gè)用于清空隊(duì)列中消息的 Purge 方法。您可以通過(guò)該方法增強(qiáng)自己的類(lèi)；換言之，雖然本機(jī) API 不提供方法，但這并不意味著您無(wú)法通過(guò)添加一個(gè)方法來(lái)向包裝添加值。
由于 OpenMsgQueue 方法返回一個(gè)句柄，并且您已將該句柄映射到一個(gè)類(lèi)，因此包裝方法返回包裝類(lèi)的實(shí)例是很有意義的。此外，該方法在執(zhí)行時(shí)不需要現(xiàn)有狀態(tài)，因此您應(yīng)該使它成為靜態(tài)的。***，需要將該結(jié)構(gòu)轉(zhuǎn)化為所需的單個(gè)參數(shù)：它是只讀隊(duì)列還是只寫(xiě)隊(duì)列。
請(qǐng)注意，這里不描述平臺(tái) invoke 聲明。
以上就介紹了為點(diǎn)對(duì)點(diǎn)消息隊(duì)列設(shè)計(jì)托管接口時(shí)需要考慮的方面。
新聞名稱(chēng)：為點(diǎn)對(duì)點(diǎn)消息隊(duì)列設(shè)計(jì)托管接口
新聞來(lái)源：http://m.5511xx.com/article/cojgogp.html
