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  

这样的帖子应该发在海阔天空里吧！
在那里灌水的比技术区多多了！
呵呵！对你以上的“遭遇”表示同情与理解！