其实这种事情都会有两个观点。
一个观点是：建议使用自己熟悉的技术，采用简单的架构去实现项目，等到你把项目做出来了，能用起来了，客户认可了。以后的升级，那是你就可以比较轻松的采用其 它的架构来重构，这样你的风险，压力就相对减少很多了。
而这回，我想顶一下第二个观点：
其实如果你对代码要求比较严格的话，你就会经常发现，你的代码有很多东西可以抽取出来，或者做在公共的模块，或者作为框架的底层，我们就简单的拿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/archive/2006/11/26/1414852.aspx