解决UI框架难题

我最近受命为大型的基于Web的应用程序（超过1000个视图！）推荐并指定瘦客户端体系结构的组件。它必须基于Java，所以突然出现的第一个显而易见的问题是用Java构建如此大的Web应用程序的最佳方法是什么？……又可以分解为当今世界上有哪些便利Web应用程序开发的最佳框架是什么？又可以是分解为就技术，功能和商业标准而言，哪个框架最合适？-显然，这3个条件类别中的每一个都可以进一步分解为详细的独立层次结构。 哪种框架会导致代码/工件结构合理且可维护。哪个框架将支持众所周知的可用性模式。哪种开发方法最合适？可以进一步细分为哪个框架将保证高水平的生产力…哪些可以进一步细分为哪种框架/工具（集）支持以下方面的明确    分离：以及UI设计和编码问题的顺利交接？……可以进一步细分为哪个框架将允许工作流并行化？     

因此，简而言之，人们只需要选择最好的“技术功能商业”框架，这也可以确保以可接受的成本交付应用程序！

听起来很简单吗？……嗯，如果只需要从2个或3个UI框架中进行选择，并且是2020年的话，也许是吧！

如今，如果人们在Internet上扫描UI框架，发现的信息将不堪重负，并且很难有效地浏览。从人们对诸如“ 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，通过避免完整的页面刷新来提高应用程序的响应能力。

• 它基于上述开放标准。  

• 它通常提供了一个丰富的窗口小部件库，如果没有，则可以与其他窗口小部件库结合使用。

• 屏幕开发人员使用HTML和JavaScript编写代码，并通过API支持小部件和通过异步服务器调用进行的数据交换。

• 需要一个良好的服务器端MVC框架。

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

这些解决了客户端和服务器端的需求。这些框架实质上使Java Swing或Eclipse SWT编程模型适应了Web。它们与轻量级Ajax工具包的不同之处在于：

• 开发语言是Java。开发人员仅在特殊情况下才需要编码HTML，Javascript。 

• 该框架将用Java编写的屏幕布局和行为代码编译为浏览器呈现的Javascript。  

• 服务器端应用程序开发也是由框架驱动的。无需单独的服务器端MVC框架。

• 它通常提供了一个丰富的窗口小部件库，如果没有，则可以与其他窗口小部件库结合使用。

工具包

这些可同时满足客户端和服务器端的需求。这些是由Adobe，Microsoft和Sun等公司推广的完整的Web应用程序工具包。他们的USP是使用快速开发工具的丰富Internet应用程序。其他主要功能包括：

• 需要在每个浏览器中将运行时解释程序作为插件安装。

• 它通常基于自定义脚本和布局语言以及数据交换格式。

• 框架推动了客户端和服务器端应用程序组件的开发。无需单独的MVC服务器端框架。

5.仅限服务器端的UI框架

这些仅解决服务器端的需求。这是一篮子框架，这些框架不仅有助于开发接受和处理Web请求的应用程序组件，而且还可以汇总页面视图并将其呈现给浏览器。它们应与Lightweight Ajax Toolkits或Web 1.0 Technologies结合使用。

5A.查看技术

尽管这本质上是服务器端框架/组件，并且代表MVC框架的“ V”部分，但由于该领域中的可用选择多种多样，因此值得单独使用。View技术的主要职责是管理动态Web内容。这可能涉及完全动态HTML生成或将动态内容与静态HTML + Javascript合并。   

流行的View技术包括：

• JSP（Java服务器页面）+ JSTL（JSP标准标记库）

• Velocity和Freemarker（模板引擎）

•  XSLT（Xml –> HTML）

5Aa.ViewAggregation Technology

本质上是一种网页布局和装饰框架，可提供一致的外观，导航和布局方案。它可以在5A中提到的任何View技术之上运行。

从体系结构的角度来看，这引发了许多有趣的组合或样式。一些有效的是：

A.传统和保守–（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进行调试，重构和代码维护要好得多，并且请记住，在大型企业业务应用程序中，至少需要35％的精力用于UI层开发，并且在其中至少有70％用于屏幕布局和行为开发。  

我们当中有些人可能不想屈服于风格D的专有（许可）IDE驱动的方法，因为人们真的需要使用IDE来获得它所带来的生产率收益。但是，RIA Toolkits提供的UI功能的丰富性远远超过其他任何Styles所提供的，并且仅此一项可能会偏爱Style D，尤其是在竞争对手的产品已经提供的情况下。                   

样式B是向前迈出的一小步，我认为大多数企业都希望将其用于后台应用程序。与其他任何样式相比，它具有更多的运动部件，并且样式B本身内可能存在许多子组合。不过，由于依赖于经过时间考验的设计模式，因此它是最可靠的。尤其在大型应用程序中，一个日益严重的大问题是“ Javascript Mayhem”。太多的内容被简单地写入，很快就变得笨拙，难以管理，跨多个屏幕重复并且难以更改，测试和重构。在这方面，一切都不会丢失。可以采取面向对象的方式来进行前瞻性的思考和努力来构造Javascript的使用。

因此，我们有了它，可以选择几种建筑风格。可能还有更多，请分享您的想法和评论。选择样式后，下一步就是评估Dojo和YUI或Struts 2和Spring MVC或GWT和Wicket之间的样式中的框架。互联网上充斥着这样的比较，因此应该使用自己的PoC进行备份。