“轻量级”的Struts+Spring融合

很多朋友的习惯是:
struts-config+ActionApplicationContext
维护Struts+Spring(我对这两个文件同时维护深恶痛绝!!)
ServiceDAOApplicationContext+hibernate.xml(sql-mapping).xml注入DAO和Service.

 

假如不考虑ORM的xml,那么就是struts-config+ActionApplicationContext+
ServiceDAOApplicationContext三个文件来注入.

 

尽信框架不如无框架,我从来没用过这样”标准”组合,我觉得维护两个配置文件来维护Action很恶心,

但是我自己用了个简单的办法,使得Struts+Spring能方便的融合到一起了,虽然经不起很多复杂的推敲,但是对于一般简单的逻辑是没什么问题的

 

struts-config+ServiceDAOApplicationContext两个文件搞定Action->Service->DAO->DataSource全套注入,只要维护Struts-config,applicationContext,ORM三个配置文件全部OK

 

我的方法如下:

struts-config.xml
<action name=”user” parameter=”userService”
path=”/userAddAction” scope=”request”
type=”com.kelody.action.UserAddAction”>
<forward…../>
</action>

applicationContext.xml
<bean id=”userService”
class=”com.kelody.service.UserService”>
<proterty name=”userDao”>
<ref local=”userDAOProxy”>
</property>
</bean>

 

然后在BaseAction.execute中手工读取parameter,从Application中getBean.
在BaseAction加入一个新的abstract
doAction方法,签名基本等同于execute,而入参多一个IService接口.

最后的Action如下:

UserAddAction extends BaseAction{
public ActionForward
doAction(actionMapping,form,request,response,IService
service){
UserService us = (UserService) service;
us.add(form);
…….
}
}

 

这样配置的关键就是将action的paramter字段用来简单注入Service,而注入过程由BaseAction保证,当然,以后左右的Action不能再复写execute了,而是extends
BaseAction转而实现新的含有Service入参的doAction方法

 

不管怎么样,就是省却了Spring维护Action的那步.所以配置上会简单一些.

 

有问题的朋友欢迎来信探讨:skylovers531@gmail.com

联通SMS网关及平台开发总结

子曰:学而不思则罔.

 

本次开发耗时2个月,目前已进入接近一期最终交工的进度,是时候写总结了.

 

 

通过这次开发,在具体技术上学习到了:

1 NIO,以前开发使用过,但是并不深刻,这次领悟要深了许多,但是独立线程读取Socket和Regist
WriteKey的问题还是没有解决.留下了一点遗憾.

2
Spring:第一次简单使用,看了一本Spring的电子书就开始用,但是用的地方并不多,在这里Spring仅仅充当了一个ClassLoader的作用.并没有真正使用到IOC和AOP特性.

 

 

 

开发技巧:
1 在VO类中采用ResultSet2Object方法来代替JDBC取结果时挨个Set的尴尬,如果那样的话,在此VO存在大量DAO
Method的时候,更改属性简直就是一场恶梦.采用此方法后,只需在VO中添加相关属性及get/set方法,并在ResultSet2Object中多一个Set就可以搞定所有的DAO操作(在Select语句中我还是乐衷于使用’*’而不是具体的列名,在table是VO的完全映射时,配合ResultSet2Object的好处显而易见).

 

2
模式:对Command模式,Factory模式更深入的理解,对接口的进一步理解,虽然这里我仍然采用了大量的abstract
class.目的只有一个:相同的代码我只想写一遍.

 

3
为每一个包做一个BaseInterface(BaseClass)和一个Exception非常的有必要,这样上层只需考虑下层的异常即可.在某些关键的包,如DAO包中,务必使每个Method都抛出自己的DAOException,这样你的Service
就不会为千奇百怪的SQLException而担心了.

 

4
虽然我是一个Java程序员,但不可否认在必要的使用数据库特性非常重要,一个200行的Procedure也许可以代替Java500行以上的代码,并且Procedure拥有更好的安全性和速度.当然,我这么说是因为到目前为止我还没有遇到项目最后换数据库的情况.

 

5
为某些重要的类写一个Main方法很好用,你可以在里面示范这个类的使用方法,在必要的时候还可以用做TestCase.

 

6
在项目下建一个testcase包,把平时开发内部测试所写的TestCase都放进去,并在每个TestCase中加入详细的注释说明这个case是做什么的,这个习惯有时能省50%以上的额外编码时间.(假设你完成了一个DAO,那么他的TestCase代码几乎可以经过简单修改就放入Service层使用,如果你TestCase写的比较好,那么下次同伴遇到类似的方法时就可以省下70%以上单独写TestCase的时间了.)

 

7
预见性编码.请为可能以后用到的方法进行重载编码,不但可以保证你以后开发进度的畅快,并可以解决其他同事或者许久之后的自己等一些对目前代码不熟悉的人使用.我想大家在使用JDK或者一些良好的开源包时都会有出现以下感叹:

“需求改了,我需要一个和此方法类似的方法.咿,作者竟然已经将此方法重载了很多次,其中恰好有我需要的,太好了!”

 

 

 

方法学和重构:
1
重构,再重构.这次开发过程中,由于需求的修改和添加,我几乎后期天天都在花70%以上的时间做重构,代码结构变化很大,但每次重构代码质量都能上一个档次.虽然偶尔会引来部分小Bug,但是详细的测试保证了一切的正常运行.

 

2.敏捷方法和XP.此次开发除了配对开发和文档需求外,我努力实践XP开发过程方法.关键组件(业务管理,计费)都经过了不止一次的60%以上的修改.前提是:修改前可以正常使用,修改后能够更好的工作.得到的好处:在进度紧迫的时候可以尽早给用户提供可用产品,并在时间充裕时可以进行功能升级.代价:早期没有好的设计,导致后期升级修改工作量比较大.但是我对此的解释是:关键组件需求变更频繁,就算我们在早期就花了大量的时间来设计再设计,那么当某些重要需求变革时,仍然免不了导致前期设计失败的情况.后果:项目延期而且并不一定能保证最终结果让用户满意.当然,用户有权利提出需求的变更,如果此时你的模块已经运行起来了,那么你可以很好的将需求放在二期或者重构时来加入.用户会表示理解并可能会默认你的项目延期.毕竟之前需求所提到的模块已经在运行了.

 

设计已死?不,没有,虽然从上两点提出了一些对于频繁变更需求的项目的解决方法.但是良好的设计仍然会让你在重构或者XP推倒以前代码的时候减少工作量.当然,我这里指的是概要设计以及编码期间的预见性编码(分析以后可能会用到的方法并提前重载或额外开发)

 

 

项目管理:
这个项目给我最大的收获就是实质性的学到了很多项目开发管理的经验并把我以前脑子里面的idear可以用于实践.

 

 

遗憾:
开发进度太快,在某些基础模块采用了最简单的办法.以后可能带来性能隐患.
早期的概要设计不是非常的到位,在模块接口部分有些粘黏.
在此项目开发过程中,自己在工作和感情的问题上处理的不太好.

(原创)Microsoft的反击

今天上线HOTMAIL,发现提醒我试用Windows Live.选择后,发现新的Windows Live
Messeger也开始试用了,虽然比网上先前说起的英文版晚了近一个月,但是还是很开心的,因为身边没有其它朋友,所以也不知道是不是大规模的开始公测了,Live
Messenger正在下载,但是新版的Live
Mail貌似GMail,看来比尔大叔的目标Google无疑,外加今天看了很多关于Vista和Office
2007的消息,新的技术征战一触即发,微软果然不是吃素的,原来只在EN语言中争夺的市场现在竟然蔓延到了ZH的市场中来了,不过遗憾的是Gmail目前还没有ZH语言的支持,Google要奋起直追啊,最近在公司不知为什么上不了Google.com了,只能上被YG过的Google.cn,郁闷至极.

 

 

刚看完李连杰的霍元甲,对争强好胜多了一份理解,Mic为什么要战胜Google呢?呵呵,这种中庸的儒家思想看来在商场中一点都没用了,还是信奉法家的王道比较有前途,题外话了.

 

每一次的技术革新总是带来用户的最新体验,虽然目前关注的还只是IT圈里的人(我IT外的朋友很少关注MiS和Google的战争,或许他接到了Live的通知也不会有什么反应的,还是机械式的点确定->Next).但是无疑大面积的普及之后,会带来更多更美好的用户体验.新技术还是值得夸耀的,HOHO~

 

看了一下Live
Mail网页的源代码,果然是我恶心的AJAX,也许是自己JS水平不高,我一直对AJAX持有很强的敌意,不就是JS发起一个XML
Request然后将Reponse解析成Object然后放在页面展现嘛,用户体验是好多了,但我总感觉有些治标不治本.本人浅薄,自己一点简单的想法是以后用户的操作全部XML化,OS就是一个大的浏览器而已,所有的按钮界面什么的全部由规范来执行,也就是说所有的OS只要可以正确的解析Server的XML
Response就可以展现属于自己风格的应用程序界面了,而所有的请求都是XML Response.当然,这一切的生成和发送都是由OS
Kernal来实现的,而不是恶心的JS.这个想法跟Java的Write Once Run
Everywhere是不是有些相像呢?但是一旦这样,所有的OS将失去自己的固有应用程序,使得Application not
depends on someone
OS.我想MS是一定反对这样的,因为也许我们可以使用廉价的Linux+低廉的WBNC(Web Binding Net
Conncting)+免费的MS Office(或者Google Web Office)+各种各样的Online
Game就可以使用目前最主流的应用了.Sun一定会高兴的,10多年前提出的Net
Computer借助Google之手又得以复活,HOHO~

 

现在下结论都为时过早,究竟鹿死谁手还须得静心等待.

 

PS:.net的同行惨了,Live架构的出现也许会导致.net架构的重新升级,看来大家又有的忙活了.