這個系列的文章不只是為了向大家介紹成果，同時也是開發過程的記錄，也是一個腳印吧。

為什麼選擇jdbcTemplate

    本人在開發的過程中接觸到的持久層包括 hibernate 、mybatis .. 兩種持久層框架都感覺不盡如人意。首先說說hibernate,hibernate對資料庫操作進行了重量級封裝，使得對資料庫的操作完全是面向物件的操作，其中的面向物件操作成為很多開發人員的福音。但是hql就不那麼好了，hql雖然是sql的簡化版本，但是hql畢竟是在sql上面套了一層，如果有一天你的程式在那一塊操作變的異常的緩慢，那麼對hql優化將會變得比較間艱難，而且hibernate底層大量使用了反射機制，雖然其反射大多數情況都是在程式初始化時執行的，但是在程式執行過程中反射機制也是存在的。而mybatis是持久層的輕量級封裝，在mybatis中如果需要進行某一個操作，首先需要定義mapper，然後再定義mapper.xml。在mapper.xml中需要完成model對映，需要寫上介面相關的sql,這個過程作者認為重複性的工作比較大。如果能夠在java類中直接書寫sql，同時還能夠進行簡單的物件操作，那麼程式將既擁有hibernate的部分有點，又將擁有mybatis的部分有點。在今後的開發中，我將會使用spring jdbcTemplate進行開發。

jdbcTemplate 的缺點

jdbcTemplate開發時不需要定義那麼多的xml，不會有hql語句優化艱難的缺點，但是其存在一個致命性的問題，就是太過基礎，基礎的就像在使用jdbc進行操作。這嚴重影響了開發的效率。不過也正因為其基礎性非常好，才使得其優化具有可行性。

如何進行jdbcTemplate的優化

      我認為提高jdbcTemplate 開發效率的方式是使用其具有面向物件的功能，比如說我們可以定義方法使得傳入物件就可以完成單表CRUD操作、比如說，我們查詢的時候，查詢介面可以完成到DTO或者model的對映。

        這個時候我們就會想這在model上，或者dto上寫上註解。使得欄位可以與成員變數對映，然後使用反射操作將結果對映成物件。前面定義註解我認為是可取的，因為寫註解的開銷並不是很大。當然如果實體很多的時候，重複性也是會讓人受不了的。不過我之前寫過一個eclipse的外掛，該外掛可以給定義的實體批量的添加註解，雖然新增的註解有時候會有誤差。但是修改比重複的新增效率總會提升很多很多吧。而後者使用反射來進行CRUD操作我認為是不可取的，因為反射的效率太慢了。

        我的想法是自動生成實體相關的crud操作例項化物件，然後建立可以map物件儲存 實體的class與crud操作類相對映，每次對某個實體進行crud操作時，就從map中獲取的操作物件，然後呼叫該操作類完成操作即可，業務處理過程將不存在任何的反射操作。

理想如此豐滿，現實意味著妥協

       我採用javasist+freemarker的相關技術完成了相關的功能，由於javasist的很多的限制，比如說javasist不支援泛型，javasist生成的類有時候會不能通過java虛擬機器的安全校驗，結果不是像前面說的那麼的完美，但是最終的結果應該是等效的。