我来谈谈web框架

首先声明:一家之言,权当笑尔。

我做web有些时候了,刚开始做.net时遇到一个前辈写的框架,一堆xml配置,配置用什么.net控件,样式是什么。一个页面用一个xml配置就出来了。哎呀我的个天,那个xml真是看着头疼啊,做梦都是xml。一个不小心配错了就报错,但是找错又不直观。动态生成的控件,无法使用vs调试。每添加个新功能还是得改代码。我当时很纳闷,为什么要这样写呢?抛弃了.net提供的优点不说,把个逻辑混成一团分不开,我好郁闷,二次开发就是这么痛!现在想一想,大概是她想保持界面风格一致吧,受够排版的苦了?这也造成了我对xml极度的反感。

后来做java,刚开始很喜欢框架,见个新框架就很激动,抱着这个action看又抱着那个action看。但是实际用的过程中比起.net组件化的架构确实要差一些,后来自己写了个框架sopo。意思是简单好用。

JSF

我最先用的是jsf,那时国内都是struts,而jsf正是刚提出来的时候,大概公司的技术领袖被sun的王婆卖瓜吹得晕乎了,决定使用jsf。我就开始jsf了,要自己开发jsf组件,开发一个还好,开发那么多我就烦了,这是什么个东西??我要开发个组件要配置一堆xml,经常配错就报莫名其妙的错误,你根本想不到是配置造成的。哎我嘞个去,又是这个xml。jsf组件开发也是MVC模型,写个组件起码要3个类(我写个tree组件有十几个类),它还有个绘制器的概念,意思是说哎呀你写个模型可以使用不同的绘制器来展示就可以了,像手机的用手机绘制器,浏览器用html绘制器。刚开始我还蛮认同的,后来一到写绘制器就心里就窝火:你XXX的能在html上站稳脚跟就不错了,还手机的,看我以后还用不用你@#¥@#¥。还有个特点就是慢,如今jsf都这么多年了,我打开一个jsf的网站,感觉就是-----慢。也难怪,本来一步就可以做好的事情,非要拆开一二三四五六,能不慢吗?这也反映了java普遍存在的问题---学院学究,摊子太大,脱离实际!

后来换了家公司,他们也是上了jsf的套,正好找到我来救火,一看,匆匆忙忙组件都不会写,还用的richfaces。richfaces写组件还要依照他们规范来写客户端脚本。不过我倒觉得richfaces做的要好些,他的实现理念还比较创新,与ajax结合的比较好。我还发现了richfaces当时刷新请求机制的顺序问题,让richfaces的开发者改了。这家公司后来也怕了jsf,决定不再使用。

Tapestry

后来听说tapestry性能好,我就开始试用。它是基于模板的展现,但是我一直想找动态创建组件的方法,没有。看了源码,也没什么好办法实现!找资料,很少,而且我觉得tapestry4之前都比较复杂,虽然tapestry5似乎是意识到了这一点,大刀阔斧的删了很多鸡肋。但是一直没有火起来啊!用的人少,自己用的也不是很顺手。我对他的兴趣也越累越淡,弃之。

webwork

口口声声是说基于组件的,但是我想找到动态创建组建的方法,还是没有??页面上要写组件,代码里面还是要通过id才能获得@@。晕……其他的我也不想说了,不是我想要的。

Strust2

Struts出来的早,别人用着都好,MVC嘛,简单就是美,我认同硬道理--实际用的人多就是有道理的。struts2是基于webwork2的, MVC很好,我首先自己开发标签,(开发struts2标签见我的文章 http://kazge.com/archives/71.html)。感觉不爽。

来看看广为流传的struts2的特点:

Struts2 Action有以下特点:
—  Action类完全是一个POJO,因此具有很好的代码复用性。
—  Action类无需与Servlet API耦合,因此进行单元测试非常简单。
—  Action类的execute方法仅返回一个字符串作为处理结果,该处理结果可映射到任何的视图,甚至是另一个Action。

前两点我很赞同,第三点我很痛恨,因为涉及到xml.我还要用到过导航继承,那个配置哦,配得我头都是昏的。我真搞不懂,不就是个导航吗?有必要搞得这么复杂吗?实现个页面要配置几个地方,这是个问题啊。曾经有人问我一个struts2的程序为什么那样写,就是个登陆的功能,这个跳到那,那儿再跳到远方……他看半天没看懂¥%¥%。哎---无语。

struts2还提供多种“特性”,什么多种模板语言啊,titles啊,实际你用起来,觉得完全就是忽悠人,就算是吃饱了撑着一个项目里面用多个模板语言,它实际支持的很不好,这毛病那毛病,你用了就知道。

许多细节地方我都不说了,反正我用struts2很恼火。

SpringMVC

这个和spring结合的话倒是很方便,不过它的映射仍然需要配置或者是写注释。每写个页面要写个模板,控制器,配置mapping。我比较反感的是不能省略配置映射这一步---哪那么多配置的!!不过相对于其他来说,还是比较简洁的。如果以“保持团队编程风格一致”这个理由(我可是很不认同这个观点)来说非得选个框架的话,我就会选它。

 

我相信许多熟手都会自己掌控住一个灵活的适合系统的框架。通过对底层几种技术的柔和应用来构建系统,而不需要这些另外的框架。毕竟,那只是个框架,它只提供了一种工具而已。


Total views.

© 2013 - 2018. All rights reserved.

Powered by Hydejack v6.6.1