http://www.garrettdimon.com/archives/aspnet-vs-front-end-architecture
該文作者細數了他在使用ASP.NET進行開發的過程中遇到的6點不爽的地方，主要都集中在前臺架構上，包括大量內聯的風格標簽、不同瀏覽器生成不同頁面代碼、失敗的標記設計、缺乏語意一致性、服務器端label和客戶端label的脫節、服務器端ID和客戶端ID脫節等等。尤其當你想使用標準的CSS，構建數據結構和表現分離的清晰頁面時，ASP.NET的一些默認的內部處理可以讓你對ASP.NET為何這樣做完全無語。比較有趣的是本文后面的回復，其中有不少與樓主同病相憐的網友，還有來自微軟員工的為ASP.NET辯護的聲音。
我一直對MS在很多設計思路和決定上心存疑慮，不明白為什么MS硬是要自成風格搞自己那一套蹩腳的所謂"規范"或"標準"，似乎在鼓勵大家follow一個并不清晰、多少有些混雜無章的設計架構，其實為了方便它實現更cool的WYSIWYG開發工具。就拿今天來說，本來我們項目定義好所有模塊都按BO和UI分開，BO里面的類和UI里面的類各施其責，原則上UI依賴BO，而不是反過來，按照我的理解和期望，Windows.Forms命名空間應該是由UI層來依賴，而非BO層。很顯然，因為我們的form都放在UI層，肯定是依賴Windows.Forms了，而我們盡可能把所有業務邏輯代碼放到BO層。但是為了臨時實現一個文本文件形式的log，因為我們的業務邏輯代碼都在BO層，所以為了記錄有意義的log，我們的log邏輯自然而然只能放在BO層。但是一個基本的獲取程序運行路徑的方法屬于System.Windows.Forms.Application類，讓我們不得不using System.Windows.Froms。這其實還好，我們也許不應該強求Windows.Forms一定就是只針對UI上的應用。問題是你每天都在面對類似的情況，每天都或多或少在和.NET API和框架其他部分在打架，當你使用.NET的API時間久了，自然而然你就被它帶到它的那一套思路中，你的設計也就自然而然跟著它走了，業務邏輯和UI邏輯交織在一起，當你回過頭來想把層次理清理順已經成為Mission:Impossible。因為拋開MS推薦的方式，自己實現一套自認更清晰的架構，相較"官方"的blueprint設計，代價實在有些高。
所以雖然我沒有真正開發過ASP.NET，尤其是2.0版，但我很能理解他們遇到的尷尬。