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中，作个平衡。这样在维护上面不会有太大压力。