2013年6月14日 星期五

在Web Form專案中使用Rzaor上Azure WebSites的問題

先不談問何需要在WebForm當中使用Razor WebPages,這一篇主要還是討論到的問題和解決的方法。 首先要在WebForm中使用Razor不是太大的問題,建立一個HTML Page把副檔名直接改cshtml即可:

接著我們就可以撰寫Razor語法了(我找一天完整一點介紹Razor以及他的意義,但還沒寫之前,gelis的這一篇不錯,如果你喜歡讀英文,可以看這篇)。

OK,撰寫一段簡單的程式碼如下,結果一執行,馬上發生錯誤:

我們很乖的依照指示,到web.config中改成:
<configuration>
 <appSettings>
   <add key="webPages:Version" value="2.0"/>
 </appSettings>
<system.web>
  <compilation debug="true" targetFramework="4.0" />
</system.web>
</configuration>

OK,可以work囉。


但悲劇發生在上Azure WebSites時:

本來以為是Azure websites看不懂cshtml,還我改了一陣子MIME設定,後來想想不對,如果看不懂就應該不能run MVC 的razor才對,所以又轉往另一個方向嘗試,折騰了半天,原來Azure websites尚未支援2.0。 立馬到Azure WebSites設定畫面調整看看:

設定完成之後,搞定囉。 cshtml的razor頁面可以混在WebForm中上Azure囉...

先寫到這邊(其實還有一個在cshtml page中存取資料的問題...改天繼續)

==================================
沒事幹嘛在ASP.NET WebForm中混入Razor呢?

其實我也有點掙扎。 這一陣子有個案子是以MVC來設計,開發的同仁跟我說,選用MVC其中一個原因是他討厭WebForm中的WebControl,總是沒有辦法隨心所欲的調整UI,不管套入CSS或是選用哪一套JavaScript Framework,實在都不容易整合。

某種程度上我是接受的,因為WebControls自己reder出來的HTML,想要調整很難不寫後端C#(VB) code,來微調WebControl的HTML輸出。但如此一來,前端又有寫死在.aspx中的JavaScript,後端又有透過C#(VB)動態產生的JavaScript,整個頁面的呈現就算能夠達成我們要的效果,但已經讓後續維護越來越困難。

這是很多人選用MVC的動機之一...但,如果這只是唯一原因...對專案來說背後的代價也不算低。

因為寫慣了WebForm(或Windows Form)的開發人員轉往MVC會有一段掙扎的時間(我發現反而原本從沒寫過WebForm或WindowsForm的開發人員卻比較容易進入),而且MVC要寫的漂亮,且維持MVC的精神,其實對於物件(OO)操作的觀念需要比WebForm對於OO的觀念來的更精實才行。而在採用MVC來開發之後,處理UI時想要用比較短(比WebForm或Silverlight還快)的時間來達成相同的效果,大概非得用上一兩套JS Framework不可,這些都增加了入門的門檻和學習(開發)的成本。 而URL Routing和Controller的觀念也是必須的,導致我在專案中想讓ASP.NET WebForm開發人員立刻接手MVC開發工作,常常會發生一些衍生的成本。

為了兼顧網頁UI呈現的自由度,又不想用MVC這麼大一套架構,因此我們最近開始採用Razor Page在WebForm專案中,搭配自己的code generator(關鍵其實在這裡 :) ),並依照專案的不同選用JS Framework。這會迫使開發人員必須放棄WebControls來設計UI,而直接用HTML/JS來處理,搭配Razor Page以提高開發的效率。

(那為何不用inline ASPX? 可參考上面gelis那一篇中的解釋)

這是一個嘗試(也就是說我也不確定這樣一定是好的,如果有想法非常歡迎一起討論)。在.NET Web開發的領域中,已經累積了相當多不同的技術,傳統的WebForm有WebForm的好處,MVC有MVC的優點,Silverlight有Silverlight的價值,Razor有Razor的便利...也因此,在熟悉每一種技術之後,看看怎麼讓開發成本最低,後續的維護便利、程式碼的重用性最高...是我們在開發專案的目標。

沒有留言: