我最近受命為大型的基于Web的應用程序（超過1000個視圖?。┩扑]并指定瘦客戶端體系結構的組件。它必須基于Java，所以突然出現的第一個顯而易見的問題是用Java構建如此大的Web應用程序的最佳方法是什么？……又可以分解為當今世界上有哪些便利Web應用程序開發(fā)的最佳框架是什么？又可以是分解為就技術，功能和商業(yè)標準而言，哪個框架最合適？-顯然，這3個條件類別中的每一個都可以進一步分解為詳細的獨立層次結構。 哪種框架會導致代碼/工件結構合理且可維護。哪個框架將支持眾所周知的可用性模式。哪種開發(fā)方法最合適？可以進一步細分為哪個框架將保證高水平的生產力…哪些可以進一步細分為哪種框架/工具（集）支持以下方面的明確    分離：以及UI設計和編碼問題的順利交接？……可以進一步細分為哪個框架將允許工作流并行化？     

因此，簡而言之，人們只需要選擇最好的“技術功能商業(yè)”框架，這也可以確保以可接受的成本交付應用程序！

聽起來很簡單嗎？……嗯，如果只需要從2個或3個UI框架中進行選擇，并且是2020年的話，也許是吧！

如今，如果人們在Internet上掃描UI框架，發(fā)現的信息將不堪重負，并且很難有效地瀏覽。從人們對諸如“ UI框架比較”之類的關鍵詞進行的google搜索次數來看，從519萬起，UI框架難題本身也是一個相當相關的問題。

因此，這是一種可以幫助解決UI框架難題的方法的第一手資料。提醒您，沒有任何一個“最佳”解決方案。只有（明智地）考慮并理解了您已經做出和未做出的所有選擇的理由之后，對于給定的需求而言，只有最合適和可以接受的東西！

我使用了處理復雜性/信息超載的古老原則-“抽象”。

用Wikipedia引用–“抽象是通過減少概念或可觀察到的現象的信息內容而進行的概括過程或結果，通常只保留與特定目的相關的信息”。

遵循這一原理，可以輕松地得出一些“ UI框架抽象”，并開始將可用的框架/工具包/技術放入/分類到這些“抽象桶”中。

1. Web 1.0技術（JavaScript，DOM，HTML和CSS） 

這些僅解決客戶端的需求。這本質上是2004年前的Web應用程序構建方式，具有以下特點：

•  開放標準

•  無異步調用，因此–完成頁面刷新。

•   沒有豐富的小部件庫。

•  需要一個良好的服務器端MVC框架。

2.輕量級Ajax工具包

同樣，這些僅解決客戶端的需求。Ajax本身并不是一項技術，而是諸如HTML，CSS，Javascript，DOM，XML，JSON之類的一組技術，以及一種用于在瀏覽器和服務器之間異步交換數據的方法，從而避免了完整的頁面重裝。這種框架類型的主要特點是：

• 正確應用了Ajax，通過避免完整的頁面刷新來提高應用程序的響應能力。

• 它基于上述開放標準。  

• 它通常提供了一個豐富的窗口小部件庫，如果沒有，則可以與其他窗口小部件庫結合使用。

• 屏幕開發(fā)人員使用HTML和JavaScript編寫代碼，并通過API支持小部件和通過異步服務器調用進行的數據交換。

• 需要一個良好的服務器端MVC框架。

3.基于Java組件的Ajax工具包

這些解決了客戶端和服務器端的需求。這些框架實質上使Java Swing或Eclipse SWT編程模型適應了Web。它們與輕量級Ajax工具包的不同之處在于：

• 開發(fā)語言是Java。開發(fā)人員僅在特殊情況下才需要編碼HTML，Javascript。 

• 該框架將用Java編寫的屏幕布局和行為代碼編譯為瀏覽器呈現的Javascript。  

• 服務器端應用程序開發(fā)也是由框架驅動的。無需單獨的服務器端MVC框架。

• 它通常提供了一個豐富的窗口小部件庫，如果沒有，則可以與其他窗口小部件庫結合使用。

工具包

這些可同時滿足客戶端和服務器端的需求。這些是由Adobe，Microsoft和Sun等公司推廣的完整的Web應用程序工具包。他們的USP是使用快速開發(fā)工具的豐富Internet應用程序。其他主要功能包括：

• 需要在每個瀏覽器中將運行時解釋程序作為插件安裝。

• 它通常基于自定義腳本和布局語言以及數據交換格式。

• 框架推動了客戶端和服務器端應用程序組件的開發(fā)。無需單獨的MVC服務器端框架。

5.僅限服務器端的UI框架

這些僅解決服務器端的需求。這是一籃子框架，這些框架不僅有助于開發(fā)接受和處理Web請求的應用程序組件，而且還可以匯總頁面視圖并將其呈現給瀏覽器。它們應與Lightweight Ajax Toolkits或Web 1.0 Technologies結合使用。

5A.查看技術

盡管這本質上是服務器端框架/組件，并且代表MVC框架的“ V”部分，但由于該領域中的可用選擇多種多樣，因此值得單獨使用。View技術的主要職責是管理動態(tài)Web內容。這可能涉及完全動態(tài)HTML生成或將動態(tài)內容與靜態(tài)HTML + Javascript合并。   

流行的View技術包括：

• JSP（Java服務器頁面）+ JSTL（JSP標準標記庫）

• Velocity和Freemarker（模板引擎）

•  XSLT（Xml –> HTML）

5Aa.ViewAggregation Technology

本質上是一種網頁布局和裝飾框架，可提供一致的外觀，導航和布局方案。它可以在5A中提到的任何View技術之上運行。

從體系結構的角度來看，這引發(fā)了許多有趣的組合或樣式。一些有效的是：

A.傳統(tǒng)和保守–（1）Web 1.0技術+（5）僅服務器端UI框架      

B.現代而保守–（2）輕量級Ajax工具包+（5）僅服務器端UI框架

C.現代且不太保守–（3）基于Java組件的Ajax工具包

D.現代與前沿–（4）RIA工具包

那么我該選擇哪種組合/風格呢？還是我可以做出2個選擇？當我做出選擇時需要權衡哪些選擇？特定的樣式會有助于實現我的目標（繼承）嗎？尋找靈魂的問題，對不對？

我們正在處理的抽象級別只能幫助消除或擱置“樣式”，而這是“不舒服的”。例如：

樣式A可能已完全被其他樣式取代，確實應該考慮隨著時代的變化而進行現代化。   

我們中有些人可能會“感覺到”，樣式C實際上是信念的飛躍–作為一般做法，您怎么能指望我不要碰Javascript和HTML，基本上我不相信Java-to-Javascript編譯器足以處理我多年來使用DHTML完成的所有工作。這可能會吸引一種稍微保守的樣式B，盡管它會失去樣式C的BIG好處，即用Java語言本身編碼的UI元素布局和行為的細粒度組件化。使用強類型語言（如Java）比使用Java進行調試，重構和代碼維護要好得多，并且請記住，在大型企業(yè)業(yè)務應用程序中，至少需要35％的精力用于UI層開發(fā)，并且在其中至少有70％用于屏幕布局和行為開發(fā)。  

我們當中有些人可能不想屈服于風格D的專有（許可）IDE驅動的方法，因為人們真的需要使用IDE來獲得它所帶來的生產率收益。但是，RIA Toolkits提供的UI功能的豐富性遠遠超過其他任何Styles所提供的，并且僅此一項可能會偏愛Style D，尤其是在競爭對手的產品已經提供的情況下。                   

樣式B是向前邁出的一小步，我認為大多數企業(yè)都希望將其用于后臺應用程序。與其他任何樣式相比，它具有更多的運動部件，并且樣式B本身內可能存在許多子組合。不過，由于依賴于經過時間考驗的設計模式，因此它是最可靠的。尤其在大型應用程序中，一個日益嚴重的大問題是“ Javascript Mayhem”。太多的內容被簡單地寫入，很快就變得笨拙，難以管理，跨多個屏幕重復并且難以更改，測試和重構。在這方面，一切都不會丟失?？梢圆扇∶嫦驅ο蟮姆绞絹磉M行前瞻性的思考和努力來構造Javascript的使用。

因此，我們有了它，可以選擇幾種建筑風格?？赡苓€有更多，請分享您的想法和評論。選擇樣式后，下一步就是評估Dojo和YUI或Struts 2和Spring MVC或GWT和Wicket之間的樣式中的框架?；ヂ摼W上充斥著這樣的比較，因此應該使用自己的PoC進行備份。