|
|
拋磚引玉，提出一些知道的做法，歡迎大家提出更多做法。
對于網(wǎng)站來說，UI最終的形式無非是（X）HTML + 腳本 + 樣式，現(xiàn)在的問題是怎么樣生成這些前端的元素，在以下幾個(gè)方面達(dá)到平衡：
（假設(shè)有開發(fā)和前端兩種角色，前端負(fù)責(zé)表現(xiàn)邏輯和表現(xiàn)，而開發(fā)負(fù)責(zé)業(yè)務(wù)邏輯和業(yè)務(wù)數(shù)據(jù)）
1） 開發(fā)人員的工作量，工作難度
2） 前端開發(fā)人員（后面省略為前端）的工作量，工作難度
3） 產(chǎn)品（假設(shè)前端屬于產(chǎn)品部）對UI的改動(dòng)需求能否快速落實(shí)（能否只依靠前端實(shí)現(xiàn)）
4） 服務(wù)端的壓力（客戶端的性能問題暫時(shí)不考慮）
（怎么發(fā)現(xiàn)自從翻譯了《微軟應(yīng)用架構(gòu)指南》之后，寫什么都是翻譯的口氣了）
第一種方式：XML + XSLT
數(shù)據(jù)源是XML，由開發(fā)人員提供，XSL可以一開始由開發(fā)人員寫，以后由前端參與開發(fā)和維護(hù)。
T的過程可以在服務(wù)端進(jìn)行，優(yōu)點(diǎn)是搜索引擎友好，缺點(diǎn)是服務(wù)端壓力大。
T的過程也可以在客戶端進(jìn)行，和服務(wù)端進(jìn)行的優(yōu)缺點(diǎn)互反。
這種方式比較適用訪問量大（特別是客戶端進(jìn)行T）、交互簡單的系統(tǒng)，比如論壇，因?yàn)榉?wù)端只需要提供數(shù)據(jù)源，而XSL則是靜態(tài)資源可以在客戶端緩存。
這種方式的優(yōu)點(diǎn)是，如果前端直接維護(hù)XSL，那么在開發(fā)不介入的情況下可以直接對頁面布局等進(jìn)行調(diào)整，并且可以做到最好的性能。
而缺點(diǎn)則是，學(xué)習(xí)成本比較大，如果在客戶端進(jìn)行轉(zhuǎn)換那么搜索引擎支持會(huì)不好，而且XSL相對比較難以維護(hù)，實(shí)現(xiàn)復(fù)雜邏輯成本比較大。
最常見的方式，基于控件，由控件生成HTML，開發(fā)也可以直接操作服務(wù)端控件。這是一種開發(fā)人員主導(dǎo)的方式。
這是一種普適的方式，什么應(yīng)用都可以支持。缺點(diǎn)是不太利于實(shí)現(xiàn)UI快速改動(dòng)，前端很難參與ASPx的維護(hù)，因?yàn)楹芏郩I都是由控件進(jìn)行，開發(fā)人員很可能在后端操作控件進(jìn)行一些UI的修改。
第三種方式：純粹的Javascript + 服務(wù)端數(shù)據(jù)源
所有和呈現(xiàn)相關(guān)的邏輯，都由Javascript來寫（可以依賴jquery,jtemplate等組件），以AJAX方式從服務(wù)端獲取數(shù)據(jù)進(jìn)行數(shù)據(jù)的填充和一些業(yè)務(wù)邏輯的實(shí)現(xiàn)。
這是一種前端主導(dǎo)的方式，會(huì)寫大量的腳本來實(shí)現(xiàn)邏輯，需要的數(shù)據(jù)從服務(wù)端獲取。
這種方式比較適合前端互動(dòng)比較豐富的應(yīng)用，比如網(wǎng)頁游戲。
優(yōu)點(diǎn)是，前端對頁面的布局、行為有很大的自主權(quán)，并且服務(wù)端的壓力也比較小。
缺點(diǎn)是，需要寫大量的腳本代碼，難度大并且容易出錯(cuò)，并且容易出現(xiàn)安全問題。
第四種方式：模板引擎
模板引擎通過基于HTML的模板加上各種預(yù)定義的占位符來實(shí)現(xiàn)數(shù)據(jù)的動(dòng)態(tài)填充。在保證了UI靈活性的同時(shí)也保證了非常高的性能。
這種方式對于需要有多界面的新聞系統(tǒng)、博客系統(tǒng)，甚至每一個(gè)版塊布局都不同的論壇系統(tǒng)來說很適用。
雖然足夠靈活，但是前端和開發(fā)的配合還是雙向的，也就是前端還是需要知道開發(fā)提供的數(shù)據(jù)結(jié)構(gòu)。
并且，對于交互比較復(fù)雜的應(yīng)用來說，可能需要用模板引擎預(yù)定義的腳本來寫很多邏輯，造成難以維護(hù)。
這同樣是一種普適的方式，只不過更適用于面向互聯(lián)網(wǎng)的網(wǎng)站,而不是面向局域網(wǎng)的內(nèi)部應(yīng)用。
雖然MVC已經(jīng)在UI和UI邏輯方面實(shí)現(xiàn)了很好的分離，但是我覺得還是很難在開發(fā)沒有介入的情況下直接對頁面的布局等進(jìn)行調(diào)整。
第六種方式：在服務(wù)端為HTML的適當(dāng)位置動(dòng)態(tài)注入數(shù)據(jù)
這是一種比較新穎的方式，在服務(wù)端加載HTML作為模板文件，然后寫代碼修改HTML中的dom元素，為元素填充數(shù)據(jù)。
比如一個(gè)a.html配合a.shtml，a.shtml（httphandler）加載a.html然后解析HTML文檔，從數(shù)據(jù)庫加在數(shù)據(jù)填充到HTML中，輸出這個(gè)HTML。
前端提供的HTML文件可以直接使用，不需要加任何模板標(biāo)簽，不需要加任何控件，所有數(shù)據(jù)由代碼填充進(jìn)去。
可以像jquery一樣支持各種方式來搜索數(shù)據(jù)的填充路徑，也可以把一段html作為模板，循環(huán)復(fù)制成一個(gè)列表頁面。
優(yōu)點(diǎn)是，前端維護(hù)HTML/腳本/樣式，開發(fā)人員寫代碼生成數(shù)據(jù)，填充數(shù)據(jù)，徹底的分離。
缺點(diǎn)是，前端不能改變一些涉及到路徑的元素（比如我們通過className來定位元素，前端改變了className就不行），還有性能可能會(huì)差一點(diǎn)。
第七種方式：在服務(wù)端為HTML動(dòng)態(tài)載入數(shù)據(jù)，在客戶端注入數(shù)據(jù)
還是以HTML作為模板文件，只不過這個(gè)數(shù)據(jù)組裝的過程在客戶端進(jìn)行，相比第六種方式有更好的性能。
也就是服務(wù)端不用解析HTML文檔，直接為HTML文檔中加上一個(gè)JSON數(shù)據(jù)片段，這些數(shù)據(jù)是這個(gè)頁面需要的所有數(shù)據(jù)。
然后，在服務(wù)端使用ScriptSharp等框架編譯時(shí)生成填充數(shù)據(jù)到HTML的腳本，這個(gè)填充過程由客戶端執(zhí)行。
代碼還是像第六種方式一樣寫，但是這段代碼會(huì)完成兩個(gè)工作，一個(gè)是把部分代碼生成腳本文件，第二是把部分代碼生成json數(shù)據(jù)寫到頁面上。
好像還沒看到過有現(xiàn)成的框架是這么干的，難道這種方式不太實(shí)用？
其實(shí)演變一下的話，也可以是直接寫腳本，不用ScriptSharp來生成，但是在服務(wù)端寫的很大的一個(gè)好處是可以直接利用強(qiáng)類型的實(shí)體。
想象一下這樣的偽代碼：Document.FindElement("path").Fill(product.Take(10), product => product.Name);
這樣，product這個(gè)List的前10項(xiàng)就會(huì)以json輸出在頁面上，而定位元素以及賦值的代碼也會(huì)以jquery/Javascript代碼輸出在頁面上。
優(yōu)缺點(diǎn)和第六種方式一致。
第八種方式：由服務(wù)端生成HTML
這是一種比較極端的方式，所有HTML由代碼生成，可以拼字符串也可以利用SharpDom之類的框架。
適合UI隨著業(yè)務(wù)邏輯變化非常大的流程系統(tǒng)，或者一些模板生成工具，不太適合業(yè)務(wù)系統(tǒng)。
it知識(shí)庫：有關(guān)網(wǎng)站UI實(shí)現(xiàn)的幾種方式的討論，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
