Asp.Net Web Form開發模型是否正在走向末路？

12-29

總覺得微軟搞出個這個東西有點多此一舉，好像是為了使Web編程和桌面應用編程更統一，但這就很好嗎？是不是很沒有必要呢？

走向末路了，現在的新項目沒有任何理由使用這套技術棧。

因為網站項目的存量代碼遷移到MVC成本太大，去年我還搞了 javascript + ashx的折中辦法。

但是它的思想(封裝控制項 + 事件驅動)，被以react為代表的部分前端方案又找回來了。區別在於之前webform的事件都要伺服器驅動，同時封裝的html也是在伺服器渲染，對畫網頁的又不友好。

那個年代的瀏覽器和終端性能，webform採用這種方案已經領先很多了。基於form提交的模式又有巨大兼容性，移動端在中古Symbian手機上用WebForm mobile可以做出一個動態網頁。

2005年上大學開始我用http://asp.net 1.1畫網頁的時候，我同學還在用 java servlet的doGet往外輸出html代碼。後來他們學會了JSP，我已經girdview加一大堆textbox button開始做MIS站點了。後來他們掌握 Struts Spring Hibernate 的時候，我已經http://Asp.net AJAX無刷新頁面，面向Web Service轉型了。

當然後來我就廢了，沉迷於畫網頁做網站，acm一點沒刷，畢業面MSRA被3輪帶走，哎。

利益相關: 6年WebForm工作經驗

WebForm的控制項封裝性是比較好的，適合做企業開發，代碼復用率高。MVC可以更好的利用各種前端組件，適應html5和各種標準。
WebForm確實可以認為已經謝幕，但其本身已經非常成熟，如果有合適的項目，不失為一種選擇。

最新的web動態程序開發中，mvc被淘汰了。現在多用json api加純html加js框架，根本不需要mvc，mvc是重發的，是在ajax方案以前用的一種折中方案。微服務，移動互聯網，websocket，讓json api大行其道，一次開發，n個終端調用，最大程度上節約開發成本，統一了數據api，實現服務端代碼復用，節省伺服器帶寬。伺服器端從當初什麼都管，到只控制數據輸出，主要是瀏覽器的js引擎性能越來越強，伺服器只要管好數據api就好了。移動APP的開發，html5的普及，雲服務的興起，讓傳統的mvc框架沒可伸縮性，不具備一次開發多處使用，所以數據api的出現是一種必然，伺服器只要關注數據，各客戶端負責數據處理及轉跳，伺服器又回到了cgi開發模式，但不需要輸出煩人的html，css，js，那是界面客戶端的事。你的程序想做大，必然會進軍多個平台，包括不限於電腦，安卓手機，安卓平板，安卓手錶，安卓tv，蘋果手機，平板，tv，手錶，微信等等，要想這麼多平台共用一個api，最好統一規劃伺服器的數據api，才能更好實現高伸縮性，實現代碼復用。這種數據api方式，對開發語言要求低，多用java，c#，php，python，node.js，但這種開發成本無疑是相對較高，主要適合互聯網應用開發。這種方法對數據和界面分離徹底，伸縮性強，應是未來主要互聯網開發模式。

對於文章或圖文展示引入搜索引擎流量的建議用cms，用模板html js，生成靜態或偽靜態html，加採集器後可一天生成n多，這種不屬於真正的web動態程序。

webform用於快速開發，常用於開發後台管理，xx管理系統，這種使用量比互聯網小，以功能為主，並發不太高的場合。隨著伺服器性能提高，帶寬加大，這種開發在這種場合比mvc方便快捷，主要是開發速度快性價比高。不要指望一種武器可以戰勝各種情況，可以在前台用json加js開發精雕細刻，後台用webform開發以功能為主節省時間。mono的webform可以布署於linux，支持mysql，可以在資料庫層實現前台同步，用這種方法節省時間成本可觀，如果再配合代碼生成器生成框架，開發速度可超乎想像。快速實現業務功能是webform最大魅力所在。由於webform多屬內部應用，你所以看到的少，屬於倖存者偏差。

mvc介於webform和jsonjs兩者之間，快捷上沒有webform好，性能上沒有jsonjs好。常用於java開發大型組織的xx管理系統，配合資料庫，完成業務功能，常用ssh類似框架，對性能要求沒有互聯網應用高，售價較高，開發較慢。隨著jsonjs開發模式成熟，js界面庫的豐富，未來會向jsonjs方向發展。

從現在的技術眼光看WebForm的確有點過時了。跟現在的前端主流玩不到一塊去。
但其產生時對於WEB編程的簡化還是起到很大的作用，所以才會有.NET程序員只需要拖控制項的說法。
如果是才接觸http://ASP.NET或者新項目的考慮，已經不太有必要專門考慮WEBFORM了，即使需要使用，現在http://ASP.NET的統一模型也可以讓你在MVC項目中嵌入WEBFORM。有答案說複雜表單模型，這種需求用現在主流的方式，例如angularjs可能會更好一些。

特定歷史時期產物，使命已達成，現在不要碰

Webform的推出是微軟的歷史局限性造成的，使得那個年代的一批程序員為此買單，現在要重新學習MVC。Java陣營很早就有了MVC框架，微軟是在看到其巨大的先進性和優勢之後才意識到跟進，時間上晚了7,8年。

縱觀歷史，微軟一直是技術上的跟進者而不是創新者，犯了很多錯誤不過所幸後來都意識到並且慢慢的修復，直到納德拉時代，才開始逐漸追上歷史的步伐。

http://Asp.Net Web Form開發模型是否正在走向末路？

走向末路？也許。過時？也許。
做過一點webform的開發，感覺確實相當笨重。
就拿自帶的dataview什麼的來說，即使拚命地調優，我也覺的我還不如引用個js的table插件來得好用又好看又輕便。
不愛用就別用唄，喜歡微軟系，搞搞mvc不是挺好？

總覺得微軟搞出個這個東西有點多此一舉

看到這句話我就有點不樂意了，真的說的很蠢。你什麼時候開始寫的代碼，為啥你就能評論一個東西是不是多此一舉了？
webform 2002年搞出來的，什麼概念？
html4.01 1999年出的。
元老級框架，yui 2005年，jquery 2006年。
中間這幾年呢？別人工程師精力充沛想搞點好用的東西都不行了么？
不是所有的探索都是有價值的，不是所有的試驗都會成功。
失敗就沒有價值了嗎？用成功來衡量失敗，是不是太功利？

是否走向末路主要看兩方面，首先是http://Asp.Net最新的發布的版本是否有帶有WebForm的相關更新，其次是使用WebForm的人是否越來越少了。

WebForm有多少人在使用，沒有找到統計數據，但從幾個大控制項廠商的論壇熱度來看，討論WebForm的話題要比MVC的多，這至少表明了WebForm在第三方收費控制項的使用量上要比MVC多，但這個數字是否存在一個下滑趨勢，我就不得而知了。

Telerik Developer Forums
ASP.NET - UI Developer Community

個人認為基本不存在什麼末路問題，WebForm的事件模型很適合開發複雜表單的網站，這點其實是MVC的軟肋，看起來微軟的開源策略中不包含WebForm，但這或許是微軟把開發者留在Windows平台的一個策略，而且WebForm的成熟穩定這點也是很大優勢
個人對.NET開發這的建議是：複雜的表單用WebForm，注重內容展示的網站用MVC，一般來說網站前端用MVC，後台管理用WebForm比較好

不可否認webForm的開發效率是很高的，使用它來開發企業管理類項目是比較適合的，尤其是用戶量不大，性能要求不高的web類軟體，如果是互聯網項目，絕對是不適合用來做view層的。

我覺得http://asp.net webform 還好，用著還不錯

看應用場景吧

一路走好WebForm，畢竟陪伴了我這麼多年

html1,2,3,4真是多此一舉,很沒必要,直接上html5不就好了嗎?
幾年後題主是不是還要說es標準1,2,3,4,5都是垃圾,6也不乍地?
事實上webform的思想在當時(200x年)還是很先進的,只是web的發展,讓其不能再滿足現在的需求而已,但其思想,我認為還是有部分傳承下來了.
webform應該退休了,但絕不能算是沒有意義.

假設一下，如果.NET取消對webform的集成，當大家用MVC開發一個不足千人使用的企業管理系統的時候，就會想到，真不行咱們通過遊行讓微軟把webform還給我們。

一個產品也有它的生命周期,很多都是根據社會發展需求來的.不能因為不能滿足現有的需求了,就懷疑曾經出現的輝煌期.