閒聊：Web Site Project為何沒落？

前幾天跟網友討論到：「WSP易改又好用，何以如今在冷宮？」

照片來源

Web Site Project（WSP）與Web Application Project（WAP）是ASP.NET網站的兩種專案類型態（延伸閱讀：Web Site Project vs Web Application Project ），身為從Visual Studio.NET (2002) ASP.NET 1.0開始寫起的老芋仔，有幸見證參與這一段歷史演變。

在ASP.NET 1.1/Visual Studio.NET 2003時代，測試網頁前必須等待Visual Studio編譯整個網站，12年前，最快的CPU是Pentium 4，SSD還沒發明，主流硬碟只有5400轉的時代，修改完到看見結果的等待過程，對急驚風（對，就是我）根本是種修行。有鑑於此，ASP.NET 2.0/Visual Studio 2005時代，Web Site Project誕生了！WSP不需要.csproj列舉管理網站檔案，在資料夾放入檔案就能加入新網頁，而網頁各自獨立且即時編譯，改完.aspx、.aspx.cs存檔再重載瀏覽就能看結果，少了編譯等待，Coding過程更流暢，雙手在鍵盤敲個不停的樣子特別帥（天曉得在寫什麼妖魔鬼怪），我就是這樣愛上WSP的。

只是，WSP也有WSP的缺點。例如：跨網頁共用邏輯只能放在App_Code、暫時移出檔案很麻煩（必須改名.excluded）、原始碼會在正式台曝光（註：可靠預先編譯解決）… 等，有一部分開發者仍舊偏好先編譯再執行的做法，為此微軟推出Web Appication Project(WAP)套件，採用先前整個網站編譯為單一DLL的做法，並在Visual Studio 2005 SP1時納入內建功能，自此，ASP.NET開發者有兩種選擇：WSP、WAP，功能相同，任君選擇。

Visual Studio 2008開始，ASP.NET陣營加入生力軍－ASP.NET MVC，ASP.NET MVC採用WAP編譯模式。而歷經Visual Studio 2008、2010、2012、2013到2015，Visual Studio同時支援WSP、WAP兩種專案型別，開發者可依偏好選擇。隨著ASP.NET MVC受到愈來愈多關注，WAP可以通吃MVC與Web Form形成優勢，只能寫Web Form的WSP逐漸式微。在Visual Studio 2012，WSP的地位正式浮現警訊－VS2012將不再支援Web Deployment Project，基於開發資源配置優先順序，Visual Studio用行動說明最後的抉擇。之後VS2013、VS2015延續相同策略，WDP只停在VS2010版，淡出歷史舞台。依下一代ASP.NET 5走向，可以預見WSP，乃至於Web Form也將退出主流之列（延伸閱讀：丞相，起風了！從ASP.NET 5的變革談起）。

但有個非常有趣的現象－最近較深入了解ASP.NET 5，發現它的專案結構與現行ASP.NET大異其趣：.xproj改為負向表列，偵測檔案變更自動編譯… （延伸閱讀：TechDays 2015筆記－D2）啊哈！不需列舉檔案，測試前不需手動編譯，不正是WSP精神的重現？我想起三國演義的開場白：天下大勢，分久必合，合久必分…

回到主題，WSP是怎麼沒落的？這是群體偏好共同演化的結果，沒人能給權威解答，但我身為「看著ASP.NET長大」的老骨頭，倒是有自已的觀察。WAP與WSP各有優劣，MSDN甚至有專文比較，在此不多細數，依我的觀點，WSP主要的優點與缺點如下：

優點：

1. 檔案即改即測，一氣喝成，省去等待編譯的時間 ，讓Coding更流暢
2. 更動aspx及aspx.cs即可新増或修改網頁，不要動到App_Code、bin及web.config，甚至連網站應用程式都不需重啟（但有特例），不影響其他網頁運作。如果你高興，甚至可以直接在正式台上改程式（實務上線環境很少會這樣玩就是了）
3. 網站可以同時使用VB.NET及C#開發（實務上極罕見，可忽略）

缺點：

1. 原始碼被部署到正式主機違反一般資安原則（靠編譯後發佈或WDP可以克服）
2. 每個網頁自成DLL，載入程序繁瑣影響效能（可在WDP設定每個資料夾編成一顆DLL改善）
3. 依賴將DLL放入BIN目錄形成參照，參照關聯不明確，除錯不易。BIN目錄需簽入版控，編譯後DLL檔案日期改變形成異動待簽入假象有點困擾
4. 網頁採動態編譯，單元測試實施不易
5. 跨網頁共用的程式碼只能集中在App_Code，不像WAP可以自由調置
6. 不支援ASP.NET MVC、ASP.NET Web API
   (更新：透過一些技巧，在WSP還是有可能整合ASP.NET Web API，感謝網友忠實觀眾分享）

在我的工作環境，缺點1最致命，原始碼出現在正式主機是被禁止的，一律使用WDP先編譯再上線。而編譯策略採一個資料夾一顆DLL，好處是資料夾A的網頁有異動，上線時只更新資料夾A的DLL，將系統異動幅度減到最小。使用WDP後，更新aspx及aspx.cs增修單一網頁的第2項優點只適用於開發測試階段。而隨著時代演進，優點1愈來愈不明顯，首先是電腦硬體愈來愈強大，除了CPU變快，SSD的出現大幅提升運算效率，等待網站編譯對寫程式流暢度的影響不如以往明顯（ASP.NET 5敢採用「檔案一改就重新編譯」的模式，我想也基於「當代硬體已經很夠力」的假設，但我猜將未來應會增加手動執行編譯的選擇）。另外一方面，ASP.NET開發者多已具備架構概念，知道不該將建DB連線查資料表的邏輯一股腦塞進Button1_Click()事件，而是應該切割出企業邏輯層（Business Model)、資料存取層（DAL）另立獨立DLL。於是，愈來愈高比例的網頁修改其實是發生在企業邏輯層或資料存取層的DLL，需要編譯才生效，只剩下純UI面的異動可以即改即生效，優點1派上的用場就更少了。

在電腦硬體效能驟升與系統架構進化的夾擊下，WSP優勢不再，再加上ASP.NET MVC掘起，WebForm式微，WSP坐冷板凳的機率增加，近年來我只拿來順手寫寫展示或實驗性質的小專案，全部邏輯集中於單一網頁，改完存檔馬上看結果，充分發揮它的專長。至於正式專案，已上線專案雖然超過八成還是WebForm + WSP，短期內不可能改寫，但所有新開專案，基於會部分或全部使用ASP.NET MVC，WAP是唯一選擇。在我眼裡，即使WSP現階段還是中流砥柱，但榮景已過，只會逐漸淍零。

WSP終將沒落，但任何技術皆然（更甭提前端界那一堆短暫如煙火的「當紅」工具），都會歷經興起、全盛、沒落、消失的週期，身為開發者，也只能認識它、擁抱它、享受它、放下它，別帶一絲不捨。

這年頭身為開發者，千萬別跟你的工具、語言、程式庫談戀愛，唯絕情者得以倖存！

（別過頭偷偷拭淚）

圖說：照片是可愛的倉鼠，我永遠記得飼養介紹文章有段提醒：養牠之前必須有心理準備，倉鼠的惹人憐愛技能破表，飼主能從朝夕相處獲得難以想像的樂趣，但請記住，牠的壽命只有短短的兩年，所以遲早有一天…