決定何時實作事件架構非同步模式
更新：2007 年 11 月
事件架構非同步模式提供了一個模式來公開類別的非同步行為。在引入這個模式之後，.NET Framework 定義了兩個模式來公開非同步行為：以 System.IAsyncResult 介面為根據的非同步模式，以及事件架構的模式。這個主題將描述實作這兩個模式的適當時機。
如需使用 IAsyncResult 介面進行非同步程式設計的詳細資訊，請參閱非同步程式設計模式。
一般原則
一般來說，您應該盡量使用事件架構非同步模式來公開非同步功能。但是，此事件架構模式無法滿足一些要求；在這些情況下，您可能需要在此事件架構模式之外也實作 IAsyncResult 模式。
.gif "注意事項") 注意事項： |
|---|
實作 IAsyncResult 模式而沒有同時實作此事件架構模式的情況，是相當罕見的。 |
方針
下列清單描述當您應該實作事件架構非同步模式時所適用的方針：
將此事件架構模式當做預設 API 使用，以公開類別的非同步行為。
當您的類別主要用於用戶端應用程式中 (例如 Windows Form) 時，不要公開 IAsyncResult 模式。
當必須滿足您的需求時，只要公開 IAsyncResult 模式。例如，與現有 API 之間的相容性可能會要求您公開 IAsyncResult 模式。
如果沒有公開此事件架構模式，也不能公開 IAsyncResult 模式。
如果您必須公開 IAsyncResult 模式，請以進階選項的方式來處理。例如，如果您要產生 Proxy 物件，則預設會產生此事件架構模式，並附帶一個可產生 IAsyncResult 模式的選項。
在 IAsyncResult 模式實作上建置您的事件架構模式實作。
避免在相同類別上同時公開此事件架構模式和 IAsyncResult 模式。在較高層級的類別上公開此事件架構模式，並在較低層次的類別上公開 IAsyncResult 模式。例如，將 WebClient 元件上的事件架構模式與 HttpRequest 類別上的 IAsyncResult 模式相比較。
當相容性需要時，在相同類別上公開此事件架構模式和 IAsyncResult 模式。例如，如果您已經發行使用 IAsyncResult 模式的 API，您將需要保留 IAsyncResult 模式，以提供回溯相容性 (Backward Compatibility)。
如果產生的物件模型複雜度帶來的好處更勝於分隔實作的好處，則可在相同類別上公開此事件架構模式和 IAsyncResult 模式。在單一類別上公開兩個模式的作法，要比避免公開此事件架構模式更理想。
如果您必須在單一類別上同時公開此事件架構模式和 IAsyncResult 模式，請使用設定為 Advanced 的 EditorBrowsableAttribute，以將 IAsyncResult 模式實作標記為進階功能。如此可向設計環境 (例如 Visual Studio IntelliSense) 指示，不要顯示 IAsyncResult 屬性和方法。這些屬性和方法仍然有完整的可用性，但是透過 IntelliSense 工作的開發人員會對此 API 有更清楚的概念。
在事件架構模式之外也公開 IAsyncResult 模式的準則
雖然在之前提到的案例之下，事件架構非同步模式有許多優點，但是它也有一些缺點，而當效能是您最大的需求時，應該要特別留意這些缺點。
此事件架構模式及 IAsyncResult 模式未處理到三種情況：
封鎖一個 IAsyncResult 的等候
封鎖許多 IAsyncResult 物件的等候
輪詢 IAsyncResult 的完成
您可以使用此事件架構模式來處理這些情況，但是這樣做要比使用 IAsyncResult 模式更為麻煩。
開發人員經常會針對一般有極高效能需求的服務使用 IAsyncResult 模式。例如，輪詢完成案例就是一項高效能伺服器的技術。
此外，此事件架構模式的效率要比 IAsyncResult 模式差，因為它會建立更多的物件，尤其是 EventArgs，而且它也會跨處理序同步處理。
下列清單將顯示在您決定要使用 IAsyncResult 模式之後所應該遵循的一些建議：
當您特別需要 WaitHandle 或 IAsyncResult 物件的支援時，只要公開 IAsyncResult 模式。
當您有使用 IAsyncResult 模式的現有 API 時，只要公開 IAsyncResult 模式。
如果現有的 API 是以 IAsyncResult 模式為根據，請考慮在下一版中公開事件架構模式。
如果您有極高的效能需求，而您驗證過此事件架構模式不能滿足這項需求，但是 IAsyncResult 模式卻可以時，只要公開 IAsyncResult 模式。