ASP.NET Web Forms 4.0的革新(下)

前言：

在上一期介紹了ASP.NET WebForms的一些功能增強之後，緊接著這一期我們繼續來看在ASP.NET 4.0當中的幾個更重要的WebForms新功能，您會發現即便看似小小的調整，對於開發人員來說，在效能上或開發的便利性上，都有相當大的助益…

 

Session State Compression

 

      在過去ASP.NET 2.0與3.x時代，Session資料有兩種被存放的方式，一是被保留在伺服器端的記憶體中，另一種方式則是存放在SQL Server當中的。不論是哪一種方法，Session資料都是被序列化後才進行暫存的，因此當Session資料量較多時，將會造成儲存媒體的負擔。

      也因此，在ASP.NET 4.0版本當中，開始支援Session State Compression機制，開發人員可以在config檔案中進行如下的設定： 

<sessionState     mode="SqlServer"     sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"     allowCustomSqlDatabase="true"     compressionEnabled="true" />

      當compressionEnabled=true時，Session資料的序列化動作就會額外透過GZipStream來進行壓縮，以降低序列化所造成的Session資料膨脹，對於較大型的應用程式來說，可以得到不少好處。

Url Routing的支援

 

      而ASP.NET 4的Web Forms當中，最令人激賞的，則莫過於是URL Routing機制的全面支援。過去在ASP.NET 3.5 SP1當中，Web Forms或多或少就開始支援URL Routing機制，它讓我們在網址的呈現以及使用上更加的有彈性。

過去我們在ASP.NET當中，習慣於底下這樣的網址呈現方式：

EX：

http://myWebSite/EditProduct.aspx?Id=1

但最近幾年REST風格的網站(或REST Web服務)興起，你常常會看到網址的呈現方式變成：

EX：

http://myWebSite/Product/Edit/XBOX

      上面這樣的網址有一些好處，首先，網址可以更明確的表達想要呈現的功能，或是要後端應用程式進行的行為；其次，上面這樣的網址由於並非對應到後端某一個實體檔案(.aspx.cs)，而是透過Routing機制來轉派，因此相較過去的網址有著更高的安全性。

      也就是說，在這樣的架構下，ASP.NET應用程式的網址再也不只是對應到實體檔案的路徑，而是可用來表達要執行的功能。至於實際執行時要處理的程式碼或呈現結果的網頁，也並非一定要是由網址所指向的實體頁面。這也讓我們在開發應用程式時有更大的彈性，例如一般的部落格網站網址可能是『http://blog.ria101.com.tw/studyhost』，由於blog網站多半都可以開放給多人申請，理所當然的每一個用戶都有類似『http://blog.ria101.com.tw /申請者ID』這樣的網址。

      當然，對應到ASP.NET的後端應該都是同一套程式來處理，在過去的ASP.NET應用程式當中，我們得要煞費一番工夫才能讓網站可以接受這樣的網址設計(把參數從QueryString轉變成REST風格)，而現在，透過URL Routing機制很快地就能輕鬆搞定。

      除此之外，還有另一個顯而易見的好處，採用REST風格的網址：

EX：

http://myWebSite/Product/Edit/XBOX vs. http://myWebSite/EditProduct.aspx?Id=1

      相較於傳統網址更容易被Google等搜尋引擎查詢與檢索，畢竟上圖網址中的XBOX比起產品Id=1來得容易理解的多。

      那我們要如何在ASP.NET 4當中使用這樣的機制呢，您只需要透過新加入的Routes類別，利用MapPageRoute方法即可輕易的完成URL路由的指定，例如：

EX：

protected void Application_Start(object sender, EventArgs e) {     RouteTable.Routes.MapPageRoute(         "TestRoute", "Search/{ProductName}", "~/WebForm1.aspx"); }

在Global.asax如此撰寫之後，當使用者在網址列鍵入：

EX：

http://localhost:1031/Search/AK47

      網頁(應用程式主控權)將被導引到WebForm1.aspx頁面，而在該頁面中則可以透過底下的方式來取得參數ProductName『AK47』：

EX：

protected void Page_Load(object sender, EventArgs e) {     Response.Write("Searching Product Name : " +                 Page.RouteData.Values["ProductName"]); }

      這樣的設計方式，果然是方便容易許多，別小看這樣的機制，這讓我們開發大型的Web應用程式變為可能，配合我們後面要介紹的ASP.NET 4當中的DynamicData技術，我們得以輕易的開發出單一的一張.aspx網頁(一支程式)，即可維護後端Schema不同的各種資料表的。

      不像過去ASP.NET 2.0時代，若後端資料庫有許多資料表要處理，我們幾乎得要為每一個資料表建立獨立的一張.aspx維護頁面，即便每一張.aspx網頁上的行為與程式碼邏輯幾乎完全一樣(CRUD)。

      更有趣的是，配合URL Routing機制的普及化，連過去我們熟悉的DataSource控制項都增加了一個RouteParameter來共襄盛舉，如今ASP.NET 4.0 Web Forms可說是對URL Routing機制全面支援了：

EX：

<asp:LinqDataSource ID="LinqDataSource1" runat="server"     ContextTypeName="UrlRouting.DataClasses1DataContext" EntityTypeName=""     TableName="Customers" Where="CompanyName == @CompanyName">     <WhereParameters>      <asp:RouteParameter Name="CompanyName" RouteKey="CompanyName" Type="String" />     </WhereParameters> </asp:LinqDataSource>

      您會發現，透過上面這樣的語法，我們可以讓LinqDataSource進行資料查詢時where條件所使用的參數，直接引用URL Routing中的參數值，類似過去的QueryStringParameter，相當的方便好用。

Linq查詢的支援

 

      說到了DataSource，如果您已經開始使用Linq查詢技術，那您大概對於LinqDataSource或EntityDataSource不會感到陌生，在ASP.NET 4.0當中，還增加了QueryExtender控制項作為您在使用Linq查詢資料時不可或缺的功能。

      過去我們可能習慣透過where敘述進行資料的查詢與過濾，現在除此之外，您也可以透過QueryExtender中諸如SearchExpression、RangeExpression、PropertyExpression、或CustomExpression…等眾多不同的篩選器，讓資料查詢變得更加的簡便有力。

      例如，底下這段指令碼中的QueryExtender，使用到了RangeExpression過濾器，可幫助開發人員可輕易地達成特定範圍區間內資料的搜尋，其中我們搜尋的對象是大夥熟悉的Northwind資料庫中的Products資料表，我們設定了QueryExtender，要求查詢Products資料表中UnitPrice值介於TextBoxFrom與TextBoxTo之間的資料：

EX：

<asp:LinqDataSource ID="LinqDataSource1" runat="server"     ContextTypeName="QueryExtenderControl.Data.DataClasses1DataContext"     EntityTypeName="" TableName="Products"> </asp:LinqDataSource> <asp:QueryExtender ID="QueryExtender1" runat="server" TargetControlID="LinqDataSource1">     <asp:RangeExpression DataField="UnitPrice"     MinType="Inclusive" MaxType="Inclusive">         <asp:ControlParameter ControlID="TextBoxFrom" />         <asp:ControlParameter ControlID="TexBoxTo" />   </asp:RangeExpression> </asp:QueryExtender>

     

      查詢的結果如下，不需要撰寫任何一行程式碼，透過QueryExtender即可幫助我們輕易地找出單價在18到20之間的產品：

      這是一個時常需要撰寫資料庫應用程式的開發人員，所需要注意與關切的新功能，除了上面我們用到的RangeExpression之外，其實還有許許多多的不同的過濾器(甚至我們也可以透過CustomExpression過濾器自定篩選條件，來幫助我們輕易的完成查詢工作，對於資料庫應用程式的開發相當有幫助。

其它控制項功能的提升

 

      至於ASP.NET 4當中正式納入(其實在3.5 SP1當中就已經可以下載取得)的Chart Control就不用我多說了，從底下的這張圖片中你會發現，現在我們可以輕易的透過Chart Control，在網頁上呈現出各種精緻的圖表：

      除了圖表控制項之外，在ASP.NET 4當中，還有不少的控制項有著功能上的小幅提升，諸如FormView、ListView、CheckBoxList and RadioButtonList、Menu、Wizard and CreateUserWizard…等，這些控制項或多或少都有一些功能或呈現方式上的增強與改善，多少也可以看到微軟針對了開發社群長期以來的一些期待有了明確的回應。

結語

 

      從上面的介紹中您可以發現，雖然只是小幅改版，但ASP.NET Web Forms還是有不少功能上的增強。同時，我們也別忽略像是後面我們所要介紹到的ASP.NET MVC、Dynamic Data等新技術在ASP.NET 4當中所佔有與扮演的角色，這些技術是我們面對大型Web應用程式開發的基礎。

這幾天和幾位同是講師、作者的技術人員聊起ASP.NET 4.0，以及即將來臨的雲端趨勢，談到我們都接收到很多開發人員對於微軟在這一兩年陸續所提出的新開發技術技術感到些許壓力、或力有未逮、甚至不明白該如何導入或使用、或對其重要性有所質疑。

      但言談中一位作者提到：其實回頭想想，這幾年這些新技術的出現，幾乎都並非由微軟主導革新，反而是開發人員在社群中針對新技術提出各樣的建議，而微軟則是陸續的回應了這些真實世界中的需求。

      這些新技術的出現，可能在這個時刻您並沒有感受到迫切的需要，即便使用ASP.NET 2.0，拋開Linq、MVC…等這些新技術，開發人員還是可以完成一個不錯的中小型系統，那我們後面要討論的這些看似時髦的新技術真有其價值?

      但我得負責任的告訴大家，事實上不管是ASP.NET 4或Silvelight 4，打從Beta 2開始，在我所任職的企業以及我所經手的諸多專案中，都已經做為正式的開發工具且使用多時，但如同我們談論多年卻遲遲沒有具體行動的『產業升級』一般，面對小型需求(或是區域型的競爭)時，往往很多看似不重要的部分會被我們所忽略，在專案預算有限的狀況下，對於新技術的投資常常被列為最後的考量，諸如Unit Test技術、Design Pattren的使用、乃至於Architecture的堅持、或ALM的導入，在規模不大的軟體開發專案中常常被省略。但就如同前面提及的，面對已然來臨的全球化競爭，面對軟體的產業升級，究竟要暫時忽略新技術的出現，利用團隊已經熟悉的技能來承接專案、開發產品，或是迎接新技術的來臨，汲取當中的優點，讓開發速度與品質能夠有所提升，是專案團隊需要深思以及面對的課題。

      礙於篇幅，我們無法完整的介紹ASP.NET Web Forms 4.0所有的新功能，讀者可以至筆者部落格http://Blog.StudyHost.Com或本網站中其他的內容，在當中我們將會有更多更詳細的介紹以及範例程式碼與您分享。