`
Wingel
  • 浏览: 117590 次
  • 性别: Icon_minigender_1
社区版块
存档分类
最新评论

Re: 项目(框架)架构的抉择

阅读更多
其实如果你对代码要求比较严格的话,你就会经常发现,你的代码有很多东西可以抽取出来,或者做在公共的模块,或者作为框架的底层, 我们就简单的拿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 !!!这边也是好几次,这边又是好几次,那边又是好几次。不行了,我老老实实写个cache支持吧,于是又叮叮当当了好几天,终于,有个粗糙的cache出来了,终于速度可以看一些了。后来改进又改进,测试又测试,累死了,老子好不爽啊。 好像天下有点太平了,啊,你说我这个地方忘记更新你增加的那个子表啊,算了,没关系,我明天看一下代码,这个容易解决点。嗯,我改了那边的代码了,会更新子表信息了。什么?你说取主表的记录跟相应的子表记录列表麻烦啊,没关系,我更新一下处理resultset的公共模块,明天再说。 Oh ......对这样子复杂的查询好像现在的公共模块支持不了啊,算了,这样子的查询不要用这个公共模块,我们手动写一些代码好啊,别跟我讲这样代码结构很难看,你以为我不知道啊,TMD。 TMD的,怎么这边的SQL老是运行不了啊,不会是分页底层模块的问题吧,靠,怎么你的SQL语句有这么多order,group by,靠,还有top啊,这当然过不了了,不要吵了,现在没时间改,不理它,直接用个假分页就行了。你又说代码结构难看,小心我抽你哦。 公司新来一个程序员,看了几天代码,不停的抱怨说,这代码写得真差啊。。。。。。
分享到:
评论
2 楼 Wingel 2006-11-19  
我这篇文章是自己想像的一种场景,我本身并没有经历这些
我这个是要反驳一个观点,就是要拿熟悉的比较简单的框架做项目,不要引用一些先进的功能比较强大的框架
1 楼 daoger 2006-11-18  
这样的帖子应该发在海阔天空里吧!
在那里灌水的比技术区多多了!
呵呵!对你以上的“遭遇”表示同情与理解!

相关推荐

Global site tag (gtag.js) - Google Analytics