ASP.NET MVC框架已經進入2.0時代，本文將從ASP.NET MVC數據分頁談起，希望能對大家有所幫助。

　　在上一篇文章中，我們在一個請求中執行了IronPython代碼，通過這個方法我們可以輕松地的檢查系統運行的狀態，或對系統進行一些簡單修改。但是這種做法只能檢查系統在當前時刻的狀態，在很多情況下，我們需要對系統的請求進行一段時間的采樣。對于簡單的數據（例如每秒執行的請求數量，請求時間），我們可以通過查看Performance Monitor中相關的計數器來獲得一些概要的數據。但是，如果我們需要獲取一些系統的詳細狀態，甚至是需要根據需要進行動態改變的自定義需求，則勢必要深入到系統內部進行數據采集。因此，我們可能需要讓代碼執行“一段時間”，并將直接結果進行匯總輸出。

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

剛剛愛上MVC3.0，幾個不眠夜的學習越來越有趣。今天隨手嘗試自定義Mvc3.0的視圖引擎，雖然已成功，但是還發現有點小疑問。隨手貼出來希望大家指教指教。

　　HttpModule是向實現類提供模塊初始化和處置事件。當一個HTTP請求到達HttpModule時，整個ASP.NET Framework系統還并沒有對這個HTTP請求做任何處理，也就是說此時對于HTTP請求來講，HttpModule是一個HTTP請求的“必經之路”，所以可以在這個HTTP請求傳遞到真正的請求處理中心（HttpHandler）之前附加一些需要的信息在這個HTTP請求信息之上，或者針對截獲的這個HTTP請求信息作一些額外的工作，或者在某些情況下干脆終止滿足一些條件的HTTP請求，從而可以起到一個Filter過濾器的作用。

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

　　概述