Web框架选型思考

经过漫长的商务折磨，终于确定了自己平台规划负责人的角色，任务非常明确：采用开源技术进行组装，开发一个具备业务含义、能够进行快速开发的软件平台。

现有项目的运行情况让我认识到了一点：在持久层与业务逻辑的相对成熟的情况下，WEB层的工作最为繁重，哪怕是引入了Tiles改善布局也如此。Struts天生的缺陷，让整个项目中WEB层显得笨拙不堪，成为整个系统中bad smell最重的的区域。从软件技术大会回来的同事说，很多同行都认为B/S系统中WEB端的工作量是整个系统的瓶颈。这一点看来已经得到了业界的普遍认可。

而现有的这个平台一定是持续使用的。如果不在WEB开发上进行改善，那么这个平台显得毫无意义：在依托面向对象技术的Java平台下，大部分其它的东西都有现成并且健壮的，对我而言都是熟悉的；而在WEB层，一定要有一个具备重用、珍惜每一个可重用WEB组件的框架在支撑。由于我们这个行业的特殊性，再带宽上也应当有所考虑。

基于这些特征，我首先想到的就是面向组件的WEB框架。这里的组件一定是网页上可见的组件，能够天生穿透Java/Javascript/Html，而不是笨拙的在JSP中import javascript；或者采用不堪的JSP tag. 这么看来，具备这一特征的、成熟的框架只有Tapestry了。

然而我对tapestry还有所保留，原因有两点：一个是对大型系统的支持不足。我们要面临的系统达到十几个子系统，3000多种交易。而Tapestry模块的支持区分不足，这一点上，WebWork来的要自然的多，Struts也提供了支持（我实在是难以出口这个词，虽然Struts将我引入了MVC的门，但是我对其丑陋的设计，臃肿的配置文件充满了憎恶）。

第二是Tapestry难以理解的URL，总让人觉得诡异（刚开始觉得挺有意思），不便于书签。好在有成功的项目证明进行修改是可行的，这个工作量也应该不大。

如果我的AMOWA概念有实现，那么我一定会选择Amowa的实现。因为Amowa中异步的概念刚好满足了系统带宽的要求。Web框架的选择过程让我了解到，组件式的web框架在知识积累上有多么重要。试问一下，我们以前做的WEB应用中，web端有多少能够自如的重用？

纵然Tapestry不尽人意，我还是决定选择Tapestry来作为平台的WEB框架（有人会说Tapestry不便于测试，试问又有多少合理的项目会将业务逻辑写在XXXPage中？），对其进行一些改造是必需的，比起持续使用与知识积累带来的好处，这么点工作量算不了什么。