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代码：

 

[java] view plaincopy

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的方法，然后接着写他们“万变不离其宗”的代码。还要美其名曰“性能优越”。这种人我认为应该去写汇编才能充分展示其卓越的才干。

 

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

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

 

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