Lambda表達比代表定義和帶外方法定義的結合更清楚，且相關的額外工作只需要滿足語言定義即可。不過，它也有一些不足之處。如果某個方法的參數包含System.Delegate 這樣的抽象類型，用lambda表達式介紹特殊的問題：C#編譯器不能將lambda表達式轉換成還未明確定義的衍生代表類型。
如果不仔細思考一下，你的代碼看上去就會像是來自.NET1.0的東西。在本文中，我將告訴告訴你為什麼lambda表達式不足以被直接轉換成抽象代表類型，並且教你怎樣使得編譯器轉換你所定義的指定代表。解決方案依賴於Windows Presentation Foundation(WPF)和System.Windows.Threading.Dispatcher組件，但是嚴格意義上說，該問題不是一個WPF問題。文中所描述的問題出現在若干.NET框架中，包括Windows Forms，Office 應用程序接口和映射應用程序接口。你可以按照下列方法來處理同類問題。
無論我什麼時候使用.NET框架中帶有來自代表表格的參數的應用程序接口，我都會傾向於使用lambda表達式而不是更詳細的表達式。例如，這行代碼創建了一個System.Windows.Threading.Timer，在計時器失效時，該代碼調用了一個TickHandler方法：
tick = new System.Threading.Timer((unused) =>
TickHandler());
如果方法的內容足夠少，我就會用方法的內容替代TickHandler()方法調用。該方法大多數情況下都有效，但是當應用程序接口將System.Delegate作為參數時，這一技巧不管用。例如，我們將System.Windows.Controls.Dispatcher.Invoke()方法穿過WPF中的線程實施調用：
public object Invoke(
delegate method,
params object[] args)
現在考慮一下當我們嘗試用lambda表達式來執行這樣的調用時，將會發生什麼：
MyTime.Dispatcher.Invoke(() => DoSomething());
會出現隱秘錯誤：
error CS1660: Cannot convert lambda expression to
type 'System.Delegate' because it is not a delegate type
或許第一次看到這個錯誤的時候，你還不知道到底是怎麼一回事。當然，這的確是一個代表類型。編譯器不像人一樣的靈活。System.Delegate類型是一個抽象類型，且該類型的推理工具不能推斷出自變量或某些用於未知代表類型的返回值的數量和種類。要解決這一問題，我們必須創建一個具體的代表類型並為該類型指定lambda表達式。記住，代表類型要求你將方法視為數據。
我創建了一個WPF計時器程序來展示其工作原理，其中闡述了C#3.0 怎樣簡化與老式應用程序接口(下圖)的運行。
當你做演示的時候，該示例中的應用程序運行了一個計時器，隨著設定時間流逝，它的顏色會從綠色轉為黃色再轉為紅色。這是一個很好的演示跨線程調用的方法，因為該計時器在背景線程中運行。
按照時間的改變來更新演示要求對出自計時器的事件作出響應。計時器在背景線程中運行，所以你會很輕易地犯我們在前面提到過的錯誤。
更新應用程序
用戶界面處理的是簡單代碼。當計時器失效時它會生效，而且代碼會更新計時器的顯示。這一更新必須改變文本，或控制背景。如下所示：
MyTime.Background = newBrush;
MyTime.Content = label
計時器在背景線程上運行，所以你需要通過使用Dispatcher.Invoke()邊界線執行調用。這兩行代碼是你想列入lambda表達式的代碼，不是證明方法定義的邏輯理由。但是我之前就講過lambda不會與Didpatcher.Invoke一起運行，除非是你使用了具體的代表定義才行。這之中的一部分已經在.NET框架3.5中定義了。我們可以使用嵌入式代表定義並對它們進行分配，這些都是的該解決方案比起先前提到過的案例都要省事一些。這兩行代碼也要求一對參數：一個用於文本的字符串和用於背景顏色的顏色刷。這意味著你需要使用的代表定義要考慮到這兩個參數並返回無效值：
Action updateTimer;
在聲明變量後，你可以為代碼指定需要執行的代表變量。這裡你可以使用lambda表達式，因為Action是一個具體的代表定義：
updateTimer = (label, newBrush) =>
{
MyTime.Background = newBrush;
MyTime.Content = label;
};
現在，當計時器提出事件時，你已經擁有了一些需要執行的指向該代碼的變量。接下來要做的就只是通過Dispatcher.Invoke()使用代表定義：
if (!MyTime.Dispatcher.CheckAccess())
{
MyTime.Dispatcher.Invoke(updateTimer,
newLabel, next);
}
else
updateTimer(newLabel, next);
這一過程十分簡單，但是卻要求你反復進行，因此，我們可以讓步驟變得容易一點。
這裡其實由一個簡單的模式。事件處理器可以從背景線程中調用出來。當我們使用計時器，或者異步調用Web服務以及其他類似任務的時候，你就會看到這一行為。無論是在什麼時候，我們都不清楚自己位於哪個線程之上，我們可以調用Dispatcher.CheckAccess()來決定是否可以訪問任意用戶界面控件。如果需要從線程邊界執行調用，就必須使用Dispatcher.Invoke()。Dispatcher.Invoke()方法避免了由於使用了方法參數的參數數組而造成的若干超載問題。它使用的是一個我們想要執行的抽象代表類型。
你想要一個能檢查是否需要整理編排的單一方法。如果需要，則方法會編排好調用，否則，會調用由代表指定的方法。你虛偽方法作為System.Windows.Controls.Control 類型的成員出現。這樣使得你可以將代碼作為控件的一部分來使用。C#3.0就為你提供了這樣做的方法：擴展方法。你需要編寫一些方法的不同超載，這些使得你可以通過不同的參數來使用它們：
public static class WPFExtensions:
{
public static voidInvokeIfNeeded(
this Control widget,
Action whatToDo)
{
if (!widget.Dispatcher.
CheckAccess())
widget.Dispatcher.Invoke(whatToDo);
else
whatToDo();
}
public static void
InvokeIfNeeded
this Controlwidget, Action
whatToDo, T parm)
{
if (!widget.Dispatcher.CheckAccess())
widget.Dispatcher.Invoke(whatToDo, parm);
else
whatToDo(parm);
}
public static void
InvokeIfNeeded(this
Controlwidget, Action
whatToDo,
T1 parm1, T2 parm2)
{
if (!widget.Dispatcher.
CheckAccess())
widget.Dispatcher.
Invoke(whatToDo,
parm1, parm2);
else
whatToDo(parm1, parm2);
}
}
當然，我們也可以通過添加更多參數的方式來添加更多超載以擴展這個類。這其實是一個簡單的擴展。
有一種方法讓WPF設計師們瘋狂：他們希望用最小化應用程序接口的面積部分來簡化Dispatcher對象的使用。通過使用抽象代表和參數列表中的參數，這一對象的使用范圍被擴大了。任何帶有參數的方法都可以被拿來使用。但是，這樣做有一個不足之處。該應用程序接口更為抽象，它會破壞所有類型的安全性，而且這樣做會損壞編譯器使用類型推理的能力，從而降低工作效率。需要做的應該是添加自己的安全擴展方法的層類型，這一層類型可以在類型安全調用和更為抽象的.NET庫應用程序接口之間提供一個層。
