easymybatis的设计初衷

原创
2017/10/17 14:15
阅读数 280

凡事都有两面性,软件也一样,优点与缺点并存。

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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部