在Web Form專案中使用Rzaor上Azure WebSites的問題
先不談問何需要在WebForm當中使用Razor WebPages，這一篇主要還是討論到的問題和解決的方法。
首先要在WebForm中使用Razor不是太大的問題，建立一個HTML Page把副檔名直接改cshtml即可:
接著我們就可以撰寫Razor語法了(我找一天完整一點介紹Razor以及他的意義，但還沒寫之前，gelis的這一篇不錯，如果你喜歡讀英文，可以看這篇)。
OK，撰寫一段簡單的程式碼如下，結果一執行，馬上發生錯誤:
我們很乖的依照指示，到web.config中改成:
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的便利...也因此，在熟悉每一種技術之後，看看怎麼讓開發成本最低，後續的維護便利、程式碼的重用性最高...是我們在開發專案的目標。
接著我們就可以撰寫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的便利...也因此，在熟悉每一種技術之後，看看怎麼讓開發成本最低，後續的維護便利、程式碼的重用性最高...是我們在開發專案的目標。
留言