其實這種事情都會有兩個觀點。
一個觀點是：建議使用自己熟悉的技術，采用簡單的架構去實現項目，等到你把項目做出來了，能用起來了，客戶認可了。以后的升級，那是你就可以比較輕松的采用其 它的架構來重構，這樣你的風險，壓力就相對減少很多了。
而這回，我想頂一下第二個觀點：
其實如果你對代碼要求比較嚴格的話，你就會經常發現，你的代碼有很多東西可以抽取出來，或者做在公共的模塊，或者作為框架的底層，我們就簡單的拿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