我一直在學習ASP.NET的一些新功能，超出了我當前的舒適程度，並且我正在設法弄清楚自定義事件如何適應，從設計的角度來看。我知道他們是如何工作的，以及觀察者/用戶模式，但是似乎自定義事件並沒有被討論太多。看起來整個應用程序可以通過在整個地方註冊事件和響應來構建，然而，我們發現更多的控制器類能夠以預定的模式激發代碼位......這是OOP，但仍然有點類似程序。你多久使用自定義事件？
所以從設計角度來講，什麼時候最好使用事件？是否有某些情況下他們非常方便，但沒有其他的東西？或者是否有可能創建一個嚴重依賴它們的應用程序，程序員可以根據需要儘可能多或少地使用它們？
大多數情況下，我只是好奇它們落入「正確」設計的位置，因爲我可以很容易地重新想象一個應用程序或兩個更靠在他們身上的應用程序，而不是僅僅在控制器類邏輯按鈕被點擊。
你沒有看到在asp.net代碼儘可能多的自定義事件，主要是因爲可以觸發一個「事件」的東西往往是事物的用戶通過內置控件的人做在客戶機上像一個按鈕或什麼不是。儘管服務器本身並不與代碼「交互」，但它以事件驅動的方式執行。
您通過常規控件之一獲得回傳goind。在服務器上的執行往往本質上是非常程序化的......這只是在像Web這樣的無狀態請求/響應環境中最有意義的模式。
的asp.net頁面生命週期和服務器控件都有很多他們揭露的事件，可能火象方面的OO其實只是支持的是其本質高度程序和線性的執行路徑。
自定義服務器控件公開自定義事件就像內置控件做到讓網頁開發者有一個機制，使它們可以與不緊耦合控制交互......所以這是在那裏你會發現大多數的自定義事件。但是，如果你確實有很多不同的頁面可能會使用控件，那麼製作自定義服務器控件的成本確實是值得的。
我也經常在用戶控件中使用事件。雖然您可以將用戶控件與服務器控件非常類似，但通常用戶控件在面向對象設計原則方面往往很薄弱。通過用戶控件，通常只是試圖獲得一點關注點和封裝的分離，但是在託管頁面和用戶控件之間仍然會有相當緊密的耦合。但是有時用戶控件可能需要向託管頁面發信號通知某些條件已被滿足，並且在這些情況下，自定義事件是處理該信號的好方法，其具有比直接調用託管頁面上的方法更少的耦合。
大多數情況下，我在構建自定義控件時使用自定義事件。
在ASP.Net我不使用自定義事件的威力，因爲即使有自定義控件我試着更多地依靠現有的頁面生命週期。
在Windows窗體幾乎所有我做的是抽象成一個控制的地方，所以我使用它們相當多。
我在ActionScript 3.0中做了很多自定義事件。我提到這一點是因爲它的委託系統與.NET非常相似。
我正在創建一個可以一次排隊多個剪輯的SWF播放器。我的自定義時間軸控件會觸發ClipEnd事件，我的主應用程序會監聽並推進播放列表。如果用戶進入新剪輯或自動執行應用，我的播放列表會觸發NewClip事件。我的應用程序會聽這些並告訴時間軸開始播放下一個剪輯。所以我的時間軸和播放列表通過自定義事件共享鏈接。