asp.net Web開發框架 (3) - 如何讓asp.net WebForms也能搭配Vue.js和bootstrap並享有SPA開發架構?

你沒聽錯，事實上asp.net WebForms也能走SPA(Single Page Application)的開發架構，並且跟在前端的Bootstrap與Vue.js框架搭配得很好。

技術的使用存乎一心

記得曾經對學員說過，不管你用哪一種開發方式，只要對開發技術有足夠的熟悉，並且瞭解基本原理與前因後果(再說一次，學習時，為何永遠比如何重要)，那實在無需追逐潮流，你依舊可以在技術變遷中掌握到重點。

曾經聽過有些開發人員從WebForms轉換到MVC走了一條坎坷的路，並且轉換的理由很是讓人莞爾，這邊略過不提。但我想說的是，asp.net的MVC和WebForms走的是兩條截然不同的架構路徑，兩者並沒有取代性的問題，千萬別誤以為MVC主要目的就是用來取代WebForms用的。

順帶一提，那我認為什麼是真的有取代性的? 舉個例子，物件導向程式設計幾乎取代了結構化程式設計；資料庫存取的ORM技術，幾乎取代了ADO.NET等非ORM的資料存取技術；C#中的Linq取代了傳統的物件查找方式。這些，則是有取代性的…

所以，這一路上曾經聽過有些開發人員從WebForm轉換到MVC卻走了不少冤枉路，然後換到MVC之後卻用和傳統ASP一樣的思維在開發系統，這樣換比不換更慘。

如何在asp.net WebForms中實現SPA?

警語 : 接下來的內容很是驚悚，如果你對於asp.net WebForm或是MVC的『標準寫法』有著異於常人的堅持，不容妥協，那請自行斟酌，小心閱讀這篇。

還記得我們先前曾經說過的嗎？SPA對我們團隊來說的價值是『沒有任何從伺服器端Render HTML到前端的行為』，這麼做有哪些好處，在前面我們已經多次的提到過。

但整個WebForms的架構根本就是從伺服器端Render一堆的HTML到前端啊，這架構怎麼會符合SPA呢? 是的，這沒辦法，因為WebForms生來就不是走SPA路線的，在WebForms誕生的那個年代，根本還沒有SPA的影子。整個WebForms的行為都是在模擬傳統的Windows物件導向程式設計，因此任何的WebControls，舉凡Button、InputBox、DropdownList…全都是透過後端的HTML Render Engine動態產生的。

這導致，如果你用了任何WebControls，那根本不可能走SPA。所以，不要懷疑，如果你想得到SPA的種種好據，我們的第一個建議是，在專案中請用HTML Controls(加了runat=server的純HTML Tag)取代WebControls。甚至，你完全用純HTML Tag而不用任何的WebControls或HTMLControls我都覺得很OK。(是的，這代價不小，或失去一些WebForms的特性，但會保留MasterPage和ServerSite Events，請自行斟酌)

那這樣怎麼寫程式呢? 別急，請繼續看下去…

我們用實作來介紹這個特異獨行的WebForms SPA架構。

1. 請先建立一個基本的Empty Web Application專案，請記得勾選WebForms:
   
2. 請安裝Bootstrap、Vue、isRock.Framework.Web(重點當然還是這個)這幾個nuget套件:
   
3. 接著，請建立一個default.aspx WebForms頁面，並撰寫底下的前端程式碼，我建議讀者對照前面我們介紹過用WebAPI所撰寫的SPA，該專案的前端是純html頁面，而這個default.aspx除了附檔案是.aspx之外，也幾乎是純html頁面:
   
   請留意UI的部分是32-42行，這裡除了form tag之外幾乎都是純HTML，而上面的JavaScript和先前我們介紹過的WebAPI SPA也幾乎完全相同，唯一的差異是呼叫Service Layer API的JavaScript Function換成了CallPageMethod(注意19行)，這是指要呼叫一個名為BMI的PageMethod(並且把身高體重para傳入當作參數)…
4. 等等? PageMethod是啥玩意兒? 請開啟default.aspx.cs撰寫底下程式碼(注意9-20行):
   
   請讀者留意，這是一個WebForms的code behide頁面，我特意把Page_Load方法留了下來(雖然裡面沒有撰寫任何指令)。重點在於9-10行的PageMethod。PageMethod是asp.net中很特別的一個存在，它可以被前端HTML頁面上的JavaScript直接呼叫，並且回傳JSON…這…這行為…不就跟我們要的SPA一模一樣嗎? 是的，正是如此。
   至於這個名為BMI的Method，其中的指令碼應該不用多解釋，基本上就是跟先前介紹WebAPI版本SPA的Business Logic一樣，計算出BMI並且回傳。唯一的差別是回傳型別，這裡使用的是PageMethodDefaultResult<T>。
5. 執行的結果如下，和WebAPI撰寫的SPA一模一樣，頁面不會submit，而是透過AJAX進行所有與伺服器端的互動:
   
6. 等一下等一下，那Services Layer呢? 說好的Business Logic分離呢?
   其實，這個PageMethod本身就是API形式的存在，你完全可以把他當作WebAPI一模一樣的方式來看待(也就是Service Layer)，但差別在於PageMethod的Route(嚴格說起來是endpoint)是跟著.aspx頁面的，也就是說，每一個.aspx頁面上的PageMethod，其呼叫路徑跟WebApi的/api/ModuleName/{MethodName}不同，而是/{PageName}.aspx/{MethodName}，而框架中寫的的javaScript Function 『CallPageMethod』則是幫開發人員簡化了這個呼叫，因此注意開發人員可以在default.aspx中透過javaScript(default.aspx第19行)直接呼叫CallPageMethod即可以AJAX方式調用這個伺服器端的API。
7. 那…Business Logic呢? 不是應該抽離Service Layer嗎? 上面範例中的PageMethod(BMI)不是把商業邏輯給寫進去了?
   是的，如果你堅持在PageMethod中，不要撰寫資料庫存取或是商業邏輯，把PageMethod中的程式碼改寫成和WebAPI中一樣(只呼叫另外一個Business Logic Component)，我相當贊成。然而，這堅持很難，我們實務上也沒這麼做。這跟WebForms(.aspx)的原始設計行為有關。由於WebForms的每一個.aspx頁面本來就是為了呈現某種功能，因此相關的商業邏輯程式碼如果重用性不高，直接放在PageMethod中我覺得尚且可以接受，這個妥協並不會導致後續的維護和交接變得複雜(但最好放在同一個Region區塊中)，這樣做等於某個頁面的所有相關程式碼，都在該頁面中，我覺得管理上甚至更為方便。

但，如果考慮到重用性，你確實應該跟先前WebAPI的範例一樣，額外建立一個BO，成為獨立的Class或Project，然後再在PageMethod中呼叫調用。這樣的架構更為完善，而且日後很容易可以轉變成為用WebAPI的SPA專案。但基於對傳統的.aspx開發人員來說，要養成這個習慣不容易，因此實務專案上這部分我沒有堅持。

OK，看到這邊有沒有發現，如果透過PageMethod，傳統WebForms專案要走SPA其實可能比asp.net MVC還來的方便，也容易理解。基本上就是透過前端頁面上的JavaScript呼叫同一個頁面上，撰寫成PageMethod的C#後端API， 然後忍住不用WebControls，不要Postback(Submit)就可以了。

每一個PageMethod也可以做Unit Test，將來抽出Business Logic Component(或當下就抽出Business Logic Component，在PageMethod中不要撰寫商業邏輯，只調用Business Logic Component)都非常容易。

這一個專案架構有一個好處，可以輕易的讓舊有的WebForms專案與新架構並存混用，不需要一次全部打掉翻掉，只需要讓新的功能透過新開發架構開發，逐漸把舊的WebForms轉換成SPA架構即可。

用WebForms走SPA有何好處?

1. 首先，你不用拋棄原本的WebForms專案，卻可以用新的前端開發套件或效果(光這點就很吸引人)
   因為太多asp.net舊的專案還活得非常好，為了新的架構需要拋棄舊的專案，這得不償失，透過這樣的方式，新頁面可以跟舊頁面並存混搭，逐漸移轉，同時新頁面也可以享有新的前端套件(像是toastr、sweetAlert、眾多的前端js圖表特效…etc.)
2. 讓開發團隊成員開始熟悉SPA
   SPA肯定會是未來的Web開發走向(好吧，我說了不賭未來，這個『肯定』請讀者自己判斷)，不管以後用MVC、WebForms、或是任何其他開發方式，前後端分離的很徹底的SPA，都是較為漂亮的架構，團隊成員越早熟悉越好
3. 和設計師(designer)可以密切合作(我們自己很在意這部分)
   如同先前透過WebAPI走SPA的方式相同，你會發現這樣設計出的網頁，設計師和程式開發人員可以持續合作，共同完成一個前端頁面，不會有設計師改過開發人員就跳腳，或開發人員改完設計師就罷工的情形出現…
4. 所有前端套件都可以盡情使用
   Bootstrap，Vue…任何fancy的前端套件，在以往的WebForms專案中幾乎難以相容，走SPA架構的WebForms，跟任何前端套件都不互相衝突，讓開發人員能夠大展身手…
5. 兼顧開發速度與後續維護
   WebForms先前最讓人詬病的部分，包含重複的postback影響執行效能(PageMethod的效能不可能比優化過的WebAPI好，但會比傳統的postback好很多)、臃腫的ViewState、WebControls動態生成的HTML難以維護，與前端js框架不相容…etc，在上面這樣的架構中完全不會發生，但開發人員卻又可以同時運用Page_Load, Page Exception等伺服器端事件，也可以輕易地透過MasterPage機制處理重複使用的頁面區塊，搭配上PageMethod可以很輕鬆的撰寫新型態的SPA Web應用程式，當你用熟了這種開發方式，你會發現在測試、維護、交接、執行效能上一點都不輸asp.net MVC，雖然比走WebAPI的SPA來得稍慢，但絕對是優於傳統的WebForms。

這種開發方式是為了與早期WebForms專案(與開發人員)兼容的一種變形，能夠在最少學習成本的狀況下，讓WebForms開發人員直接踏入SPA架構領域，非常有趣。

好玩嗎?

我知道很多開發人員在WebForms和MVC之間很是掙扎，但透過上面的範例，你不難發現，其實駕駛的好，AE86也能跑贏GT-R，不是嗎?

後記 : 還是得再說一次，每一種做法的背後都有著不同的需求與原因，無法放諸四海皆準，上述做法是一種折衷和妥協，也和很多人習慣的WebForms開發方式不見得相同，提供讀者參考，使用的情境必須與你的實際需求和系統環境有所搭配或取捨才行。

範例: https://github.com/isdaviddong/WebFormsSPA

口說無憑，要更多實例? 下一篇，立刻來看看如何配合Vue.js輕易完成Data Binding…
本系列索引http://studyhost.blogspot.tw/2017/01/blog-post.html
--------------------------------------------------------------------------------------------
如果需要即時取得更多相關訊息，可按這裡加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。