網頁生命週期

HtmlHelper Class

若要在 MVC 應用程式中使用 HTML 控制項，除了直接建立 HTML 控制項之外， 也可以使用 System.Web.Mvc.Html 命名空間底下的擴充控制項，來協助建立 HTML 控制項。 該命名空間包括支援表單、輸入控制項、連結、部分檢視和驗證等的類別。

Json 序列化

JavaScriptSerializer 是 .Net3.5 才加進來的類別， 可以用來將指定的 JSON 字串轉換成物件圖形。

public string Serialize(object obj);           
public object Deserialize(string input, Type targetType);
public T Deserialize<T>(string input);
public object DeserializeObject(string input);

• Serialize ：將物件或連接之物件的圖形序列化至指定資料流。
• Deserialize ：將資料流還原序列化至物件圖形。
• DeserializeObject ：將指定的 JSON 字串轉換成物件圖形。

自訂組態設定

自訂非同步網頁

如果只要想使用非同步作業執行運算，可以使用和 WinForm 相同的 APM 技巧即可。 這裡特別指的是網頁的非同步作業，其考量點會和 WinForm 的非同步有所差異。 在 WinForm 中，非同步作業常用來執行耗時的工作，並且適時的回應使用者工作進度。 但是在 WebFrom 中，不管是否使用非同步作業，都比須等待整個網頁處理完畢後才會傳送回應到客戶端，所以網頁非同步不是用來回應使用者工作進度的。

在 WebForm 中使用非同步執行長時間工作的最主要目的是希望善用 ThreadPool 。 因為當 IIS 收到一個要求時，就會由 ThreadPool 中佔用一個 Thread 來處理要求，一直到執行完畢回應用戶端為止。 若 ThreadPool 中的 Thread 被佔用完了，IIS 就會先將用戶端來的要求加入要求佇列(Request Queue)，但是如果佇列又１達到 IIS 的上限，IIS 就會暫時無法提供服務，並回應 HTTP 503 服務無法使用 的錯誤訊息。

使用網頁的非同步作業來執行工作，它會將工作交由 CLR 的 Thread 去執行，然後釋放原先 IIS 的 Thread 回 ThreadPool 。 等執行結束再跟 ASP.NET 的 ThreadPool 請求一個 Thread 來回應要求。這樣子 ASP.NET 的 ThreadPool 就有比較多空閒的 Thread 去服務更多的 request 。

自訂 HTTP Modules and HTTP Handlers

一般狀況下，當 IIS 收到Http Request，它會視這個Request的類型，交由不同的 handler 去處理。 例如，當 IIS 收到使用者提出一個網頁 aspx 需求，就會執行 asp.net page handler 以處理請求。 當 IIS 收到的是一個 asmx 需求， IIS 就會執行 asp.net sevice handler 以處理請求。 若你須要自行處理特定的需求，就必須針對這個需求設計特定的 HTTP Handler 或者 HTTP Module。

• HTTP Module 類似 IIS 早期版本中的 ISAPI Filter ，是用來將任何需求加上某些處理，例如驗證需求或壓縮回應等功能。
• HTTP Handler 類似 IIS 早期版本中的 ISAPI Extension ，用來定義 Http 的處理程序，以處理特定型態的 Http Web Request。

這二者有個主要的不同點就是，一般 Handler 所處理的需求，都會針對特定的檔案路徑，或者特定的副檔名。

所以，若要建立一個 IIS 的擴充功能，你可以先判斷這個功能是否是針對特定的 url/extension ，來決定是要建立一個 Module 或者 Handler 。

Models

建立一個 ASP.NET MVC 網站，通常會依下列步驟來做：

1. 建立 Model
   • 建立資料庫的 Entity 模型
2. 建立 Controller
   • 使用 VisualStudio 程式碼產生器產生程式骨架 (這個步驟也會順便建立 View)
3. 調整 View
   • 移除不要的顯示欄位或表單欄位