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