共用方式為

決定何時實作事件架構異步模式

基於事件的非同步模式提供了一種模式，可以用來揭示類別的非同步運作方式。 引進此模式時，.NET 會定義兩種模式來公開非同步行為：以 System.IAsyncResult 介面為基礎的非同步模式，以及基於事件的模式。 本文說明何時適合您實作這兩種模式。

如需使用 IAsyncResult 介面進行異步程序設計的詳細資訊，請參閱異步程序設計模型（APM）。

一般原則

一般而言，您應該盡可能使用事件架構異步模式公開異步功能。 不過，事件架構模式無法符合某些需求。 在這些情況下，除了事件型模式之外，您可能需要實作 IAsyncResult 模式。

備註

在實作 IAsyncResult 模式時，若未同時實作事件驅動模式的情況相當稀少。

指導方針

下列清單說明何時應實作事件架構異步模式的指導方針：

  • 使用事件驅動模式作為預設 API，以使類別具備非同步行為。

  • 當您的類別主要用於用戶端應用程式時，請勿公開 IAsyncResult 模式，例如 Windows Forms。

  • 只有在符合您的需求時，才公開 IAsyncResult 模式。 例如，與現有 API 的相容性可能需要您公開 IAsyncResult 模式。

  • 請勿在不同時公開事件架構模式的情況下公開 IAsyncResult 模式。

  • 如果您必須顯示 IAsyncResult 模式，請作為進階選項。 例如，如果您產生 Proxy 物件，則預設會產生事件型模式，並具有產生 IAsyncResult 模式的選項。

  • 請在您的IAsyncResult 模式實作上構建事件型模式實作。

  • 請避免在相同類別上公開事件型模式和 IAsyncResult 模式。 公開「較高層級」類別的事件型模式，以及「較低層級」類別的IAsyncResult模式。 例如，比較元件上的 WebClient 事件型模式與 IAsyncResult 類別上的 HttpRequest 模式。

    • 當相容性需要時，公開相同類別上的事件架構模式和 IAsyncResult 模式。 例如，如果您已經釋出一個使用IAsyncResult模式的API，您需要保留IAsyncResult模式以確保向後相容性。

    • 如果產生的物件模型複雜度超過分隔實作的優點，請公開相同類別上的事件模式和 IAsyncResult 模式。 最好在單一類別上公開這兩種模式，而不是避免公開事件型模式。

    • 如果您必須在單一類別上公開事件型模式和 IAsyncResult 模式，請將 EditorBrowsableAttribute 設定為 Advanced，以將 IAsyncResult 的模式實作標記為進階功能。 這表示在設計環境中，例如 Visual Studio IntelliSense，不顯示 IAsyncResult 屬性和方法。 這些屬性和方法仍然完全可用，但透過 IntelliSense 工作的開發人員有更清楚的 API 檢視。

除了事件架構模式之外，公開 IAsyncResult 模式的準則

雖然事件架構異步模式在先前提到的案例中有許多優點，但它確實有一些缺點，您應該知道效能是否為最重要的需求。

事件驅動模式在三種情境下，處理得不如 IAsyncResult 模式好：

您可以使用事件型模式來解決這些案例，但這樣做比使用 IAsyncResult 模式更麻煩。

開發人員通常會使用 IAsyncResult 模式來應用於高效能需求的服務。 例如，輪詢完成用例是高效能伺服器技術。

此外，事件型模式的效率比 IAsyncResult 模式低，因為它會建立更多物件，特別是 EventArgs，而且因為它會在線程之間同步處理。

如果您決定使用 IAsyncResult 模式，下列清單會顯示一些要遵循的建議：

另請參閱