基于组件的Web框架，始终是个传说...

很多框架，都在B/S架构下，企图实现Delphi/VB/Swing风格的基于组件式的编程模型，确实，基于组件/事件的编程模型最符合我们的思维习惯，一切自然的东西都会给人带来美感和舒适的，自然的扩展性。

 

比如一个列表页面，当填完查询条件点‘查询’按钮时，最自然的写法是

 public onSubmitButtonClick() {

       //从inputField组件获得用户输入的值
       String fieldValue = inputFieldComponent.getValue();
       //调用业务逻辑层获取查询结果
       List queryResult = service.query(fieldValue);
       //将查询结果组装到listView组件
       listViewComponent.setData(queryResult);

}

你在处理按钮的响应事件时可以很专注，你的脑海中有一个页面在哪里，然后一个按钮被点击了，你所做的仅仅是处理这个点击请求。

但是，在B/S下，这是一种臆想。点查询按钮其实是一次浏览器请求提交，你的事件处理代码只是request处理漫漫长路中的一部分，你得考虑最终的响应页面是如何形成的。

在B/S下，如果你从组件式的思路出发，你想不明白浏览器刷新算是怎么一回事，是获取服务器端的组件的最新状态？也不是，当用户刷新浏览器时，他显然希望在listView中能看到最新的业务数据。

同时，你还得考虑listViewComponent的setData会引起什么后果，可能导致服务器端内存爆炸。

所以，在上面的例子中，你的代码不得不写成：

page.addListView(new ListView() {
      //定义listView如何获取数据
      public List getData() {
         String fieldValue = inputFieldComponent.getValue();
         return service.query(fieldValue);      
      }

});

 

是不是已经觉得很不自然了。

在基于组件的自然的思路中，UI组件应该是有状态的，是有形状的（谈到形状也要叹口气，b/s下组件的形状是什么？不知道，一个label可能有几十种不同的html对应写法），是可以响应事件的，而且，我们不会考虑浏览器刷新/回退等这些程序无法预知的，也无法捕捉到的用户事件。

所以，一切基于组件的web框架，到最后都沦为东施效颦式的复杂和丑陋，JSF/wicket/tapestry/click...【属个人观点，没有任何攻击意味】。

所以，还不如不要讲组件，单纯的MVC，springMVC/struts...说明白了，也许更简单些。

 

本文也作为 非常诱人的web层框架Itsnat(一) 的续篇和结篇，想对Jose Maria Arranz【itsnat的作者，大佬，很尊敬您的创新】说抱歉，在经历对基于组件的web框架的一次一次希望到失望后，我决定很长一段时间内不再关注类似框架，改而期待B/S的革命性创新，GWT算是一种革命（但目前使用起来问题多多，前面也有所提及），comet也许是，希望有类似的大变革出现。