Web应用开发实用编程指导(三)—框架都是差不多的

        谈到应用开发就一定不能不谈到框架,几乎每种语言都有他们自己的框架组件。就连以灵活性著称的脚本语言,Ruby,Python也呈现出了大量开发框架。面对如雨后春笋般涌现出的框架,人们有感于选择如此之多,于是出现了不少“框架都是差不多的”说法。

        一个有若干年经验的开发人员一定说过这样的话:“框架都是差不多的”。这话不错,而且说这话的同时那人脸上多半带着一些饱经世故的表情。老子曾说:“为道日减”,东西学到了一定程度就会进行总结、归类,发现其中相同的东西。就好比我们评判一个人的运动能力的时候,会笼统地说道协调性、力量、耐力这些技能指标。但是在谈到不同的运动项目时,他们需要的却是完全不同的技巧和规则。显然你不能把游泳比赛的规则放在自行车比赛上面。所以老子另外还说过“为学日增”,就是告诉我们:即使掌握了原理,也不要放弃学习各种新东西,新技巧,掌握它们的不同之处。既善于总结归类,又善于推陈出新,可立于不败之地。

        比如说表单参数接收的问题,所有的Java框架都有定义了自己的参数接收的方法。参数接收的总的过程不外乎就是类型转换、对象转换。那它们有什么区别呢?

        Struts2在接收参数时偏向于使用控制类的数据对象来接收,Struts2有一种ModelDeiven的接口,直接将提交的数据贯穿于request和response生命周期的始终,这体现了Struts2的重要思想:屏蔽应用程序对servlet API的依赖,使代码更加偏向业务,更加方便单元测试。但是Struts2这种做法的缺点也是显而易见的,为了使控制类完全脱离servlet做了大量的反射封装,降低了性能。成员变量式的参数接收有可能出现变量的生命周期问题,而且还要占用大量的堆内存。

        SpringMVC在做参数接收时就明智些,它保留了servlet的API,同时提供了像Struts2那样的对象接收参数方式。不同的是SpringMVC使用方法的入参来接收参数,不仅可读性非常良好,而且也没有生命周期和堆内存占用的问题,不用写任何注解和配置,简单的按参数名匹配即可。这体现了Spring的重要思想:提供各种优雅的方案供开发者选择,而不是规定某一种方式让开发者去被动接受。同时这种简单的按名字匹配的方法也体现出了新的技术潮流:配置优于编码,约定优于配置。

        当然聪明的开发者们肯定想到可以自己做一个BeanUtil来解决上述问题。但是你的util能否注入name="userList[0].userName"这样的复杂属性呢?这是一种很常见的表单注入类型,主流的MVC框架基本上都支持这样的属性注入。

        在这个框架纵横的年代里,你一定还记得那些远古时代的servlet和jdbc代码:
XX.setXXX(request.getParameter(“XX”));
XX.setYYY(request.getParameter(“YY”));
…………
try{
<span style="white-space:pre">	</span>conn.openTransaction();
	ResultSet set=conn.prepareStatement(“……….”);
	xx.setXXX(xxxx)…………..
	tansaction.commit();
}catch(e){
	tansaction.rollback();
}finally{
	conn.close();
}
        不要以为这种写法已经绝迹了,现在它一定还在你的项目的某个角落里发挥着“旺盛的生命力”,并且在你需要维护功能时突然出现把你弄得哭笑不得。如果这种写法已经泛滥,维护人员将会有一种“自挂东南枝”的冲动。

        有一类很聪明的程序员,他无论是用什么框架都可以找到获取jdbc connection的方法,然后接着写他们“万变不离其宗”的代码。还要美其名曰“性能优越”。这种人我认为应该去写汇编才能充分展示其卓越的才干。

        软件行业之所以会出现开发框架,绝对不是为了提高性能——其实框架的应用反而是降低系统性能的。框架的出现是为了简化开发的工作,让开发把更多的精力集中到日益复杂的需求上来。程序员的时间比机器的时间更宝贵:从项目管理的角度说程序员的工作量是按天来计算的,他们对时间的运用直接关系到项目的进度、上线时间等关键性问题。机器的时间是按毫秒来计算的,一个几百毫秒的改变对机器来说已经是非常大了,但是对用户来说这真的会更重要么?

        当然这不是说完全不考虑性能,性能问题可以通过后期调优,硬件升级,从代码、设计、实施甚至是需求多个方面去解决。而一个项目的扩展性健壮性,则是从一开始就大部分决定了的。因此,开个技术启动会普及一下技术规范是绝对有必要的。

        “无规矩不成方圆”,对随意性极高的软件行业来说:“无我”式的编程、充足的代码规范及其审核,是提高软件质量降低开发成本的不二法门。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值