easymybatis的設計初衷

凡事都有兩面性，軟件也同樣，優勢與缺點並存。

easymybatis也一樣存在問題。好比有同窗說到維護性問題，按個人理解應該是SQL語句的維護。若是把全部的查詢都用代碼來實現的話，這樣確實有影響。

但easymybatis的並不鼓勵把全部查詢條件都用代碼實現。easymybatis一樣支持手寫sql到xml中，跟以前的用法是徹底兼容的，甚至不用easymybatis的功能均可以。

我以前作項目是大多數是公司的IT系統，業務相對來講不是很複雜，對錶的CRUD作的比較多。每次新增一張表對它進行CRUD操做時候都要手寫sql，然而每次寫sql基本是差很少的，無非就是表名，字段名不同。長此以往就寫煩了，因此想寫個工具來幫我寫。

當初的工具也挺簡單的，根據數據庫表生成一些通用CRUD語句，而後放在xml中。對於增刪改來講，通常沒什麼問題。問題最多的仍是查詢上面。由於查詢對於每一個業務都不同。今天要查詢state=1的記錄，明天要查詢username=張三的記錄。

我要作的操做就是，先在xml中寫一條sql語句：

<select id="getByUsername" resultType="TUser">
    select * from t_user t where t.username = #{username} limit 1
</select>

而後在Dao中添加對應的方法：

TUser getByUsername(String username);

這很煩，真的，當中充斥這大量的複製黏貼。 若是Dao裏面有個getByProperty(String columnName,Object value);方法那該多好啊，意思是根據某個字段的某個值查詢記錄。

上面的操做只要這一句話就好了:

TUser user = dao.getByProperty("username", "張三");

所以能夠事先寫一段代碼

<select id="getByProperty" resultType="TUser">
    select * from t_user t where ${columnName} = #{value} limit 1
</select>

這樣的話就一勞永逸了。easymybatis作的就是這個工做。

當咱們寫了大量的類似代碼時候，就應該考慮提取和封裝了，儘可能作抽象化，簡單化，並且機器生成的sql語句確定沒問題的，不會出現把from寫成form的狀況。

可能有的同窗在用mybatis的時候會去想hibernate，用hibernate的時候會想mybatis。既然魚和熊掌不能兼得，爲什麼不虛擬一個出來呢，在功能上儘可能往一邊靠，在CRUD上面跟hibernate同樣，在自定義sql上面能夠用mybatis，豈不美哉。

如今easymybatis的核心功能是根據TUser.java自動生成一些基本的CRUD語句，如此一來咱們只須要維護TUser就好了，好比新增了一個字段，只須要在TUser類裏面新增便可。往常的作法還要在xml中逐個添加，漏加，錯加在所不免。

最後總結下吧，在使用簡單CRUD語句的時候用easymybatis，複雜SQL寫在xml中，作個平衡。這樣在維護上面不會有太大壓力。