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