使用微軟ASP.NET MVC Framework的一些感受 + 收集園子朋友發現的bug反饋

    用ASP.NET MVC快一星期了，之前是苦苦的等待，之後是苦苦的摸索和總結，現在這個MVC在我腦子裡已經有了個大體的評價，寫出來與大家分享。
    關於MVC本身的優點，就不再詳述，地球人說了好多了。
    所以我光說說微軟的ASP.NET MVC Framework（目前還非正式發布版本，為CTP版）的一些個人感受。
    這裡先確定一個個人的感情基調：我對.NET3.5絕對擁護，對MVC絕對期待。正因為如此，對裡面的不足我會不遺餘力地和大家分析探討。

    首先，ASP.NET 引入MVC這個模組不本身不能算是3.5的什麼“獨門絕技”，也不用因為使用了MVC而對.NET3.5大加讚賞（沒有貶義），因為MVC（以下說的MVC都是ASP.NET MVC Framework CTP版）的引入只能說明ASP.NET向更合理、更順應企業級的開發模式潮流又進了一步，其模式是早就存在的（我不太願意說誰抄誰的話，也不關心，對我們來說好用就行）。甚至從這個角度上來說MS已經慢了半拍。之所以說是進步，至少MVC的出現解決了我認為ASP.NET在客戶體驗和模式上的3大不足：
   
    一、網頁生命週期過長（那是相當的長）。
    二、與第一點相關的，“巨無霸”VIEWSTATE以及PostBack功能大大增加了使用者流量，使得客戶體驗大大降低（這裡不討論Ajax的彌補作用，光說最基本的WebForm模式，不然有很多可以引起技術爭論的地方）
    三、伺服器控制項自動產生的用戶端ID，使得開發人員對用戶端頁面控制（如使用js）太吃力。不得不一天到晚和.ClientID打交道，效率也太低。
    
    所以有人說MVC具有裡程碑式的意義，這點我贊同。
    下面來說說這一周不到的時間內我發現了MVC哪些值得改進和需要注意的地方。
   
    一、不是MVC本身不足，而是 Scott Guthrie 在他的教程（包括樣本源碼）中有點誤導地球人，他普遍使用了這樣的格式（下面說的這種方式需要用到MVCToolkit.dll,這裡有下載http://asp.net/downloads/3.5-extensions/MVCToolkit.zip，目前vs2008和MVC CTP沒有提供）：
    

    大家注意Html.ActionLink()裡面的"Action="後面，他使用的是字串常量"Edit"和"New"，這是Controller層中的一個方法，用於控制網頁行為。第一次看到這個，我簡直有點氣憤——.net3.5在物件導向上面花了那麼大功夫，到他手裡怎麼還要這樣引用？這也叫物件導向？況且這比起原始的Codebehinde更不利於程式員和美工的協調。讓我感覺大樓快封頂的時候，決定用草棚做頂。兩個字——失望。
    
    二、不過我信心馬上又來了，我看到了ActionLink提供了另外一種使用範型的方法ActionLink<T>，並且找到了一篇ASP.NET MVC Preview: Using The MVC UI Helpers 的文章（強烈建議大家作為基礎看看），看到了ActionLink<T>的使用已經另外一些ScottGu沒有提到的方法。
    比如Button<T>是這樣使用的：<%=Html.Button<HomeController>(x=>x.Index(),“cmdNav2″,“Home”) %>

    用Lambda運算式x=>x.Index()取代了生硬的"Index"。
    於是我開始coding……幾秒鐘後，讓我失望的事又發生了……
    當我輸到x=>x.的時候，後面的再也出不來了，看來又是一個bug！
    起初我以為這隻個是MVC調用功能上的bug，是不是這個功能他們還沒有做好？
    後來TT.NET發現其實Button<T>不是不能調用，只是不能顯示，如果先把後面的內容輸好，再完成Lambda是可以.出來的！鬆了一口氣，但這還是MVC或者是VS2008顯示上的一個bug。

    補充一下：TT.NET剛才跟我說，不是所有的ctl<T>都不能使用Lambda來自動完成，比如Html.Form<>就是可以的，那應該可以更加肯定是MVC或者說是MVCToolkit的bug了。——2007.12.18 14:2

    三、在調試的時候發現，即使你在輸入

<%=Html.Button<HomeController>(x=>x.Index(),“cmdNav2″,“Home”) %>

    的時候，忘了輸入最後一個)，編譯也不會報錯（這個問題可能屬於vs本身檢測機制的問題），而是到開啟網頁的時候，執行階段錯誤，雖然不是大問題，細心的程式員都會自己看一遍，但是由於是在.aspx中編寫，貌似就享受不到linq在.cs中編譯時間就檢查出錯誤的那種“舒適”。當然話說回來，MVC是不提倡在View層使用這些Controller層的命令的，但終歸是個遺憾。

    四、我們有時候需為了簡化網頁流程和減少字碼頁，往往把插入新紀錄和編輯地區合為一體，即同樣一組TextBox輸入框，在一個變數或者控制項的控制下，可以轉換“Insert”或者"Update"的功能。這是一種不錯的思路，也免去了這一組“TextBox”該不該複用的思想鬥爭以及複用之後一系列繁瑣的操作（即使有些MVC觀點似乎更提倡分開表示）。當你修改的時候，由ViewData傳入一個Entity，Entity裡面是某條記錄的所有值，這時候賦給TextBox顯示是沒有問題的，問題就出在這個頁面需要我們執行"Insert"的時候，我們往往會傳入一個空的Entity(如：SzwEntity szwEntity= new SzwEntity();)，這時候麻煩來了，如果你使用O/RM設計並且裡面有string欄位的話會發現一運行就報錯,我找了半天總算找到了原因：在.dbml(O/RM檔案)下面的.designer.cs中，定義publish string str;的時候，並沒有按照我SQL資料庫中Default 'xxx'賦予初始值，當我們SzwEntity szwEntity= new SzwEntity();的時候，裡面所有的string欄位都為null，這當然不能為Html.TextBox()等作為value顯示，此時int反而沒事，因為int初始預設值已經是0了。
    因此目前最好的解決辦法就是在.designer.cs中給他們賦一個初始值，比如：        private System.DateTime _EndTime=DateTime.Now;
        
        private string _UserName=string.Empty;

    他們原本是這樣的：        private System.DateTime _EndTime;
        
        private string _UserName;

    這應該是算VS2008和MVC配合上出了點小問題。如果分來開看，或許倒不算什麼bug，反而有他們各自的用意和規範在裡面。

    五、我覺得最頭疼的一個問題，應為在MVC技術層面上似乎還不那麼好解決：開啟MVC的Global.asax，我們可以看大哦這樣一句話：

            // Note: Change Url= to Url="[controller].mvc/[action]/[id]" to enable 
            //       automatic support on IIS6 

    就是說，如果你用的是IIS6（WindowsXP/2003）的話，你就勢必要使用[controller].mvc/[action]/[id]的格式，而不能“享用”[controller]/[action]/[id]了。最大的問題倒不是在美觀和這種格式可讀性的初衷上面，而是在以下兩個方面：
    1、如果到時候系統升級到IIS7(Windows2008/Vista)，所有外部的連結是不是還能訪問帶".mvc"的路徑，這面臨著一個相容性的考驗。
    2、瞭解Search engine robots 工作原理的朋友肯定都知道，我們當初煞費苦心把.aspx/asp/php/jsp“偽裝”成.html是為了什麼。對，就是為了讓Search engine robots能有對這些.html產生“好感”，便於收錄和打分，而現在的.mvc算什嗎？Search engine robots是不是可能會把.mvc後面的當做網頁參數，把.mvc當成副檔名？如果我的假設成立，天，那.mvc的遭遇豈不是很悲慘？不知道Search engine robots是否會看到.mvc之後，久久崇拜一番然後一聲歎息揚長而去。

    以上是我用了MVC之後，發覺的比較重要和“隱藏的夠深”的一些問題，不涉及整體架構的不足（比如用{$}替換機制等等）。還有一些顯示上的問題可能和VS2008本身有關，待我確認是MVC的問題之後，我會都發上來，如果大家還發現了別的什麼問題，希望一同交流，我會一併整理進來，方便大家參考！

    前途是光明的，道路是曲曲折折的 LIKE THIS～～～～～～～～haha  only a joke