其实这种事情都会有两个观点。
一个观点是:建议使用自己熟悉的技术,采用简单的架构去实现项目,等到你把项目做出来了,能用起来了,客户认可了。以后的升级,那是你就可以比较轻松的采用其 它的架构来重构,这样你的风险,压力就相对减少很多了。
而这回,我想顶一下第二个观点:
其实如果你对代码要求比较严格的话,你就会经常发现,你的代码有很多东西可以抽取出来,或者做在公共的模块,或者作为框架的底层,我们就简单的拿jdbc来说吧,
首先,是connection的管理,这点一般用jdbc熟一些的话,都会有管理connection的公共模块,虽然偶尔会碰到性能的问题,但是这点我们暂且压下不表。
我们查询的时候,每次都要用
rs.get...("name"),
rs.get...("id"),
rs.get...("age"),
rs.get...("gender"),
rs.get...("hobby"),
然后修改数据库的时候,还要拼写update语句跟insert语句,经常还要费很多时间来调试这些多余代码的问题,这时候你就想,不行,我一定要写一个公共模块,省得让我每次都要定这么多代码,于是你的第一个公共模块产生了,然后测试啊测试,改进啊改进,叮叮响,过了几天时间的考验,这个公共模块终于可以放心使用了,项目进度开始快一些了,总算不用再拼SQL了。
后来在做统计模块的时候,突然又发现,之前在用到的一些SQL函数,好像在客户要求的数据库上不怎么行啊,于是又去查了一下资料,又过了几天(可能这次不用几天),然后终于放心,所有的函数都正常了。
接着又不可避免的碰到了分页的问题,你对自己说,不用怕,我上回就写了一个分页的,没有问题!可是Ya的你突然发现,上回的那个分页是用游标实现的,这回客户是要求用SQLServer,唉,SQLServer的游标,不提也罢,想来想去,只好自己拼SQL语句来写分页了,又是count又是top,测了又测之后,又过了几天,啊哈,终于分页的公共模块也做好的,可以放心使用了,好,项目的进度又可以加快了。
做着做着的时候,发现,咦,好像这表得增加一个字段才行,增加了,然后所有查询的SQL语句加一下,所有insert跟update的代码修改一下,页面修改一下,嗯,现在应该正常了,看起来倒是没什么问题,咦,报表好像不怎么对啊,靠,这边还有调用这个表的代码,妈的,改吧改吧。磨蹭了好几个小时(当然,熟练的话,并不用几个小时),总算看起来都正常了。
这一回,这个功能中有一次用户请求,访问了好几次数据库,不行,这里应该用个cache,否则性能上会有问题啊,算了,用算法解决一下,尽量少访问数据库好了,我对cache还不熟呢。(写啊写啊,Batch Size,这样多,那样多,Fetch Size。。。,终于,看起来正常一些了)。过了一段时间,靠,这边又要访问好几次数据库,Ya的受不鸟了,性能爱咋的咋的,反正一个地方慢又不要紧。Oh shit!!!这边也是好几次,这边又是好几次,那边又是好几次。不行了,我老老实实写个cache支持吧,于是又叮叮当当了好几天,终于,有个粗糙的cache出来了,终于速度可以看一些了。后来改进又改进,测试又测试,累死了,老子好不爽啊。
好像天下有点太平了,啊,你说我这个地方忘记更新你增加的那个子表啊,算了,没关系,我明天看一下代码,这个容易解决点。嗯,我改了那边的代码了,会更新子表信息了。什么?你说取主表的记录跟相应的子表记录列表麻烦啊,没关系,我更新一下处理resultset的公共模块,明天再说。
Oh shit......对这样子复杂的查询好像现在的公共模块支持不了啊,算了,这样子的查询不要用这个公共模块,我们手动写一些代码好啊,别跟我讲这样代码结构很难看,你以为我不知道啊,TMD。
TMD的,怎么这边的SQL老是运行不了啊,不会是分页底层模块的问题吧,靠,怎么你的SQL语句有这么多order,group by,靠,还有top啊,这当然过不了了,不要吵了,现在时间改,不理它,直接用个假分页就行了。你又说代码结构难看,小心我抽你哦。
公司新来一个程序员,看了几天代码,不停的抱怨说,这代码写得真差啊。。。。。。
![](http://blog.csdn.net/Wingel/aggbug/1414852.aspx)
文章来源:
http://blog.csdn.net/Wingel/archive/2006/11/26/1414852.aspx