我不知道大家對CodeDOM的代碼生成機制是否熟悉，但是有一點可以確定：如果你使用過Visual Studio，你就應該體驗過它帶給我們在編程上的便利。隨便列舉三種典型的代碼生成的場景：在創建強類型DataSet的時候，VS會自動根據Schema生成相應的C#或者VB.NET代碼；當我們編輯Resource文件的時候，相應的的后臺代碼也會自動生成；當我們通過添加Web Reference調用Web Service或者WCF Service的時候，VS會自動生成服務代理的代碼和相應的配置。總的來說，通過和VS集成的動態代碼生成工具使我們可以“強類型”的方式進行編程，進而提供我們的效率并減低錯誤的幾率。

　　實現一個簡單的驗證(C#)

Asp.net應用程序管道處理用戶請求時特別強調"時機"，對Asp.net生命周期的了解多少直接影響我們寫頁面和控件的效率。因此在2007年和2008年我在這個話題上各寫了一篇文章：

　　在許多年前，“語言”就等同于“平臺”，例如C，C++以及最早的Ruby和Python等等。但是隨著技術發展，出現了一些通用的平臺，例如.NET和Java，逐漸這些平臺上的語言也越來越多。再后來，某些語言在不同平臺上的實現也越來越多，事情也變得有些復雜。技術在發展，但是從目前社區的討論中，我發現許多朋友的觀念還沒有跟上。簡單地說，如今的觀念，一定要從“語言即平臺”切換成“語言及平臺”，當分清“語言”和“平臺”這兩個不同事物之后，許多問題才能討論地清楚。

　　隨著IronPyhon 2.0 的發布，.NET Dynamic Language Runtime 也更加成熟了，在2.0中我們可以用動態腳本以粘合劑的方式編寫架構體系中的各種邏輯單元，既便于修改，又能靈活適合多變的業務場景。當然，我的目標是在 Platform Framework 中能嵌入腳本引擎，而不是用 ipy.exe 去執行一個“獨立”的任務。要讓.net 項目能真正跟腳本進行交互，還得需要提供腳本引擎的實現。這得提到DLR一些基本概念了。

　　在ASP.NET應用程序運行過程中，很可能會遇到各種意料之外的問題。如果在開發環境下，我們可以設置斷點，對程序狀態一探究竟。但是很顯然，在產品環境中我們幾乎無法使用這樣的狀態。也正因為如此，Dump一個內存快照并進行分析才成為一種“高級技術”，同時在線調試也成為一種需要結合技術能力、分析能力，甚至抗壓能力的工作。對于調試和解決問題的探索永遠不會停止，各成熟的技術團隊幾乎都會有一個豐富工具箱，用于應付生產環境中的各種狀況。