前幾天跟網友討論到:「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終將沒落,但任何技術皆然(更甭提前端界那一堆短暫如煙火的「當紅」工具),都會歷經興起、全盛、沒落、消失的週期,身為開發者,也只能認識它、擁抱它、享受它、放下它,別帶一絲不捨。

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

(別過頭偷偷拭淚)

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


Comments

# by 忠實觀眾

感謝黑暗大分析, 不過WSP使用Web API 是沒有問題的,請參考 http://blogs.msdn.com/b/henrikn/archive/2012/02/23/using-asp-net-web-api-with-asp-net-web-forms.aspx http://www.dotblogs.com.tw/ian/archive/2013/05/27/104900.aspx 另外現在沒使用Global.asax,改用Startup做 Route PS:小的是用WSP+WEB API開發(最新穩定版)

# by Jeffrey

to 忠實觀眾,厲害,把Controller藏進App_Code真是奇招,謝謝你的分享,已補充進本文。

# by Baggio

之前討厭用 WAP 的原因,純粹是覺得每個 aspx 都要多一個 designer 檔實在是很瑣碎,另外就是 .csproj 要列舉管理網站檔案,在多人開發的時候真的超擾人的(幸好新的改成負向表列了)

# by

你好,我想問一下每個資料夾獨自編譯的設定在哪... 我找了一下找不到 (VS 2013)

# by Jeffrey

to 唯,我是在WDP設定中指定「Merge each folder output to its own assembly」實現一個資料夾一顆DLL(詳情可參見:http://blog.darkthread.net/blogs/darkthreadtw/archive/2007/04/06/689.aspx 文末PDF文章第8頁) 。而如本文所提,VS2012/2013已不直接支援WDP專案,需改用MSBuild執行,做法請參照另一篇文章:http://blog.darkthread.net/post-2015-02-03-msbuild-wdproj.aspx

Post a comment


89 - 4 =