拋磚引玉，提出一些知道的做法，歡迎大家提出更多做法。

　　對于網站來說，UI最終的形式無非是（X）HTML + 腳本 + 樣式，現在的問題是怎么樣生成這些前端的元素，在以下幾個方面達到平衡：

　　（假設有開發和前端兩種角色，前端負責表現邏輯和表現，而開發負責業務邏輯和業務數據）

　　1） 開發人員的工作量，工作難度

　　2） 前端開發人員（后面省略為前端）的工作量，工作難度

　　3） 產品（假設前端屬于產品部）對UI的改動需求能否快速落實（能否只依靠前端實現）

　　4） 服務端的壓力（客戶端的性能問題暫時不考慮）

　　（怎么發現自從翻譯了《微軟應用架構指南》之后，寫什么都是翻譯的口氣了）

　　第一種方式：XML + XSLT

　　數據源是XML，由開發人員提供，XSL可以一開始由開發人員寫，以后由前端參與開發和維護。

　　T的過程可以在服務端進行，優點是搜索引擎友好，缺點是服務端壓力大。

　　T的過程也可以在客戶端進行，和服務端進行的優缺點互反。

　　這種方式比較適用訪問量大（特別是客戶端進行T）、交互簡單的系統，比如論壇，因為服務端只需要提供數據源，而XSL則是靜態資源可以在客戶端緩存。

　　這種方式的優點是，如果前端直接維護XSL，那么在開發不介入的情況下可以直接對頁面布局等進行調整，并且可以做到最好的性能。

　　而缺點則是，學習成本比較大，如果在客戶端進行轉換那么搜索引擎支持會不好，而且XSL相對比較難以維護，實現復雜邏輯成本比較大。

　　第二種方式：ASP.NET Webform

　　最常見的方式，基于控件，由控件生成HTML，開發也可以直接操作服務端控件。這是一種開發人員主導的方式。

這是一種普適的方式，什么應用都可以支持。缺點是不太利于實現UI快速改動，前端很難參與ASPx的維護，因為很多UI都是由控件進行，開發人員很可能在后端操作控件進行一些UI的修改。

　　第三種方式：純粹的Javascript + 服務端數據源

　　所有和呈現相關的邏輯，都由Javascript來寫（可以依賴jquery,jtemplate等組件），以AJAX方式從服務端獲取數據進行數據的填充和一些業務邏輯的實現。

　　這是一種前端主導的方式，會寫大量的腳本來實現邏輯，需要的數據從服務端獲取。

　　這種方式比較適合前端互動比較豐富的應用，比如網頁游戲。

　　優點是，前端對頁面的布局、行為有很大的自主權，并且服務端的壓力也比較小。

　　缺點是，需要寫大量的腳本代碼，難度大并且容易出錯，并且容易出現安全問題。

　　第四種方式：模板引擎

　　模板引擎通過基于HTML的模板加上各種預定義的占位符來實現數據的動態填充。在保證了UI靈活性的同時也保證了非常高的性能。

　　這種方式對于需要有多界面的新聞系統、博客系統，甚至每一個版塊布局都不同的論壇系統來說很適用。

　　雖然足夠靈活，但是前端和開發的配合還是雙向的，也就是前端還是需要知道開發提供的數據結構。

　　并且，對于交互比較復雜的應用來說，可能需要用模板引擎預定義的腳本來寫很多邏輯，造成難以維護。

　　第五種方式：ASP.NET MVC

　　這同樣是一種普適的方式，只不過更適用于面向互聯網的網站,而不是面向局域網的內部應用。

　　雖然MVC已經在UI和UI邏輯方面實現了很好的分離，但是我覺得還是很難在開發沒有介入的情況下直接對頁面的布局等進行調整。

　　第六種方式：在服務端為HTML的適當位置動態注入數據

　　這是一種比較新穎的方式，在服務端加載HTML作為模板文件，然后寫代碼修改HTML中的dom元素，為元素填充數據。

比如一個a.html配合a.shtml，a.shtml（httphandler）加載a.html然后解析HTML文檔，從數據庫加在數據填充到HTML中，輸出這個HTML。

　　前端提供的HTML文件可以直接使用，不需要加任何模板標簽，不需要加任何控件，所有數據由代碼填充進去。

　　可以像jquery一樣支持各種方式來搜索數據的填充路徑，也可以把一段html作為模板，循環復制成一個列表頁面。

　　優點是，前端維護HTML/腳本/樣式，開發人員寫代碼生成數據，填充數據，徹底的分離。

　　缺點是，前端不能改變一些涉及到路徑的元素（比如我們通過className來定位元素，前端改變了className就不行），還有性能可能會差一點。

　　第七種方式：在服務端為HTML動態載入數據，在客戶端注入數據

　　還是以HTML作為模板文件，只不過這個數據組裝的過程在客戶端進行，相比第六種方式有更好的性能。

　　也就是服務端不用解析HTML文檔，直接為HTML文檔中加上一個JSON數據片段，這些數據是這個頁面需要的所有數據。

　　然后，在服務端使用ScriptSharp等框架編譯時生成填充數據到HTML的腳本，這個填充過程由客戶端執行。

　　代碼還是像第六種方式一樣寫，但是這段代碼會完成兩個工作，一個是把部分代碼生成腳本文件，第二是把部分代碼生成json數據寫到頁面上。

　　好像還沒看到過有現成的框架是這么干的，難道這種方式不太實用？

　　其實演變一下的話，也可以是直接寫腳本，不用ScriptSharp來生成，但是在服務端寫的很大的一個好處是可以直接利用強類型的實體。

　　想象一下這樣的偽代碼：Document.FindElement("path").Fill(product.Take(10), product => product.Name);

這樣，product這個List的前10項就會以json輸出在頁面上，而定位元素以及賦值的代碼也會以jquery/Javascript代碼輸出在頁面上。

　　優缺點和第六種方式一致。

　　第八種方式：由服務端生成HTML

　　這是一種比較極端的方式，所有HTML由代碼生成，可以拼字符串也可以利用SharpDom之類的框架。

適合UI隨著業務邏輯變化非常大的流程系統，或者一些模板生成工具，不太適合業務系統。

it知識庫：有關網站UI實現的幾種方式的討論，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。