談談Asp.net網站最佳化二：關於 伺服器控制項 和 用戶端控制項(html標籤)的選擇

     本文首發 http://blog.codepubs.com/archives/130 轉載請註明出處

      記得某次面試的時候面試官問了我這樣一個問題：“談談你對viewstate的理解。”

而我當時的回答是：“我很少用viewstate，一般情況下我都是選擇禁用viewstate”

至於我這個回答面試官是否滿意，以及對我的面試結果是否產生什麼副作用我就不得而知了！ 今天我們就來談談這個 viewstate.

 

      最近換了工作，進來之後在一周的文檔閱讀與系統熟悉的情況下就開始正式參與到編碼工作了。雖然我本人水平也不咋滴，但是我在以往的工作經驗中都會盡量的做到更好，我經常會去逛逛技術部落格，比如csdn、cnblogs、51cto 什麼的，看到好的文章我一般都是收藏並加以仔細閱讀，我這人有一毛病，看到好的東西並且是實用的東西我會記在心裡，並且去應用，去實踐。所以工作兩年來，我的能力在不斷的得到提高。以至於毫不誇張的說，也許我是個演算法白癡，但是在產品體驗以及基礎效能方面我甚至超越了一部分比我工作時間長的人，當然工作這麼點時間，我也沒有遇到什麼要求高深演算法的項目。這個問題說到底其實也是態度所決定的。

        有一次有個同事問我：“你覺得對於程式開發知道怎麼用重要，還是知道為什麼這樣用更重要。”而我的回答是：“我又不搞科研，在能夠解決工作難題的情況下我知道怎麼用就可以了”。沒錯，我確實是這樣回答的，我不搞科研，我不必天天沒事幹去研究什麼演算法，因為那些用不到。就好像我們上學時候學的物理、化學一樣。如果畢業後從事軟體開發的行業，這些根本用不到（教育的悲哀）。

       上一段話和本文的主題有點衝突了，我說我只管知道怎麼用，但是不去深究為什麼會這樣用，不過需要說明的是，本文只是針對於初學者，以及系統那些必要的最佳化。so….本文討論的是很細微的，我們可以去規避的效能問題。

 

      好像跑題了！好吧，我承認我思維混亂了，我承認我寫文章的水平很爛（呵呵），我突然想起來這幾天看到某位童鞋說過：“想當年上學的時候，作文一寫幾萬字都不帶思考的，現在寫個使用者手冊（如果我沒記錯的話）都累得慌！”

 

      寫本文的起因也是源自我手頭上進行中的項目。目前我暫且不討論架構以及資料庫設計的問題。這篇文章的初衷是針對初學者能有一個提高。最起碼是最基礎的提高。

      第一、盡量減少無用的回傳次數，看圖：

如，紅色細線框起來的 超連結“編輯”，暫且不去討論這個列表是用的 GridView還是Repeater。

       這個編輯的實現是產生一個串連到 edit.aspx 頁面，並且傳一個參數過去。看看目前的實現：

ASPX：

   <img src="../images/edt.gif" width="16" height="16" align="absmiddle" />

     <asp:LinkButton ID="lbtnEdit" runat="server" CommandArgument='<%# Eval("EDR") %>' CommandName="Edit">編輯</asp:LinkButton>

CS：

protected void repEmployeeInfo_UserInfoCommand(object source, RepeaterCommandEventArgs e){    if (e.CommandName == "Edit")    {        string id = e.CommandArgument.ToString();        Response.Redirect("EmployeeInfoEdit.aspx?id=" + id);    }

 

以上可以修改為直接在 ASPX 頁面這樣寫：

<a href='EmployeeInfoEdit.aspx?id=<%# Eval("EDR") %>'>編輯</a>

解釋一下這樣寫有什麼好處：

         這是一個 用戶端的 html a 標籤，大家知道 aspx 頁面經過 解析最終呈現到用戶端的 還是 html 標籤，那既然都是html 標籤，為什麼還要讓 IIS 再去解析一遍呢？不覺得累贅嗎？

IIS 不但要把 <asp:LinkButton 解析成 html a  標籤，還要 通過 commandName 把 a 標籤的 串連 解析成  href……

上邊那個刪除我就不說了，如果是我，我仍然是寫個 a 標籤，到別地去刪除，或者是 ajax 刪除。當然有時候為了方便也是直接在頁面上這樣寫的！這個可以這樣寫。畢竟是 .NET 控制項的優勢！     本文首發 http://blog.codepubs.com/archives/130 轉載請註明出處

         第二：盡量減少頁面大小

關於減少頁面大小的問題，其實這個終歸是返回到ViewStates上了！如果當前頁面需要互動。而你又懶，非得用伺服器控制項，那是沒辦法了。但是我們可以針對 viewstate 進行壓縮吧！壓縮令談，現在說說 關於 伺服器控制項選擇的問題、

        比如我們現在有這麼一個需求，查詢出來資料，需要在頁面顯示（僅僅是顯示），一般情況下，大多數人都會選擇 Label 控制項吧！為什麼呢？因為用習慣了！就是不知道大家有沒有發現 label 控制項會在用戶端產生一個 span 標籤，而這個span 什麼用處都沒有。（別告訴我這個可以重寫，現在不討論這個問題），當然一個頁面也不可能有N多個足夠讓頁面體積大到不行的label，這裡只是提到這個細節，細節。其實我們完全可以用  <%= %>去在頁面顯示資料吧，最不濟，用Literal 也可以啊。他不會在用戶端產生無用的垃圾代碼（小心影響css效果）

 

       在現有項目（b/s web 對外 項目）中我仍然能夠發現 通過隱藏顯示 panel 來實現的一些效果。這簡直。。。，在現如今 jquery 這麼通用的情況下我們可以選擇使用jquery達到這些效果。 

      我要提一點出來，在不用互動只是單純顯示資料的頁面，請不要用服務端控制項，請關閉 viewstate ，若頁面需要互動也請盡量考慮別的解決方案（內部項目除外）

 

 

     真的真的，我已經語無倫次了，當我發現整個項目中全是.NET伺服器控制項完成的各個功能的時候我真的內傷了！（外網項目）

         第三：關於資料繫結控制項的選擇

大家都知道.net中有N多個資料繫結控制項，估計最常用的也就是 清單控制項了吧！我就挑選2 個來說：GridView 和 Repeater.

         首先談談GridView 和 Repeater 的優缺點：

        GridView 比較強大，該有的功能他都有了。分頁，編輯，神馬的。。但是他有個缺點，就是 如果禁用了 ViewState 他貌似就只能顯示資料了。。而且產生垃圾代碼較多。個人玩玩還可以。要遇到對效能要求比較高的bs 項目還是算了！況且如果禁用的 viewstate .gridview 就成了雞肋了。

          Repeater 相對 GridView 來說，他具有模版的靈活性，repeater 不會附帶產生任何代碼，完全靠模版去實現，可控性比較強。

 

       總之，個人玩，或者小型項目，內部項目用gridview都行，只要BOSS同意，但是要是發布到外網的項目。還是用 repeater。最起碼樣式容易控制，不會產生額外代碼而增加頁面體積。有時候頁面體積太大網速再慢點，頁面的載入速度影響還是蠻大的！

       當然，如果你做的項目不是自己用，而是用來忽悠客戶，也可以用 gridview

 

 

我實在寫不下去了。。。

最後再囉嗦一點，外網B/S項目的效能有時候不單純是網速所能影響的。頁面載入的快慢和很多東西有關係，最起碼，這篇文章提到了頁面體積。儘可能是減少頁面體積也是 ASP.NET 網站最佳化的一部分！

 

     本文首發 http://blog.codepubs.com/archives/130 轉載請註明出處