修理俺的系统架构(一)

说说修理前俺们的架构:

主体框架还是延续Struts(1.1)+Ajax(Json-rpc)+Spring(1.2)+hibernate(3.1)的组合

偶们框架的功能点:
spring的事务管理,spring对hibernate的封装,当然Spring IOC也是不能少的,而Struts则对对其进行了改造,用过webwork的同学都知道,webwork里是使用的ActionContext来封装的request等操作,而在我们的架构里,同样利用xwork的原理,对struts进行一番改造,用起来跟webwork的用法基本一致,也就是Action里的方法已经没有那些讨厌的罗嗦的参数,对servlet的request,reponse等操作,都是由ActionContext来完成,但是有些同学讨厌的formbean没有去掉(废话,如果再不保留点,直接用webwork好了),另外,使用ajax技术(json-rpc)来做一些页面的校验处理和复杂页面的部分数据的交互.

在结构上严格分为三层,Action,Service,Dao层,每一层的实现类均要实现一个接口,如果你要说我是滥用接口,我暂时不会反驳,确实是这样,但是我有我的理由,后面会提到.

其实从架构上看一个产品或者一个项目,我认为主要有几点,

1.开发的效率,你手下的兄弟用你做的架构开发起来举步唯艰或者需要你不停的去解释,这个时候,我建议需要重新审视自己的架构.其实有时候,从项目和产品的效益出发,我倒不是很反对代码生成器,虽然我认为这对编程者自身的学习不利.

2.架构的稳定性,架构就像房子的地基,如果在稳定性上或者说性能上出现问题,那无疑也是致命的

3.异常处理,其实我们平时大多就技术层面讨论异常,比如我在业务层对异常做一些封装,他就会直接往上抛等等,实际上异常的处理是一门学问,在技术层面上与你的架构相适应,在业务层面上,异常怎么呈现给用户,以什么方式呈现给用户.我举一个例子:比如说我们的架构对异常的处理,由于spring集成hibernate都是rutime异常,所以,我们采用直接向上抛到action层,请不要说我的做法不对,因为这个不是重点,关键是我们接到异常该怎么处理?最初,我们的处理一致是:返回到错误页面,然后告诉用户,数据库发生异常,请联系管理员,确实,这种情况是数据库有问题了,这个肯定需要管理员来解决,但是,这里面我们是否应该分离一些异常,比如,有一些外键约束的异常,如,我想删除一个用户,但是这个用户关联的帐号,所以,在这种情况下,我是否可以提示他,"此用户下有帐号,不能删除",这样是不是更能让用户满意?如果能不转到错误页面,而采用ajax的弹出框提示,是不是会更好一点?说个题外话,web2.0的时代,拼的不就是用户体验吗?

4.日志的处理,日志又分为后台日志以及业务日志,简单理解,后台日志是给开发人员用来修理bug,替用户排忧解难时的线索,而业务日志,多时呈现给用户看,比如,用户xxx登陆,时间...,什么操作成功等等.
5.功能组件化