论坛首页 Java企业应用论坛

想改造下ibatis,不知道有没有前途。。。

浏览 15233 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-05-20  
刚看了2天ibatis,感觉有些地方不太好用,准备改造一下,还请用的比较多的朋友指点下靠不靠谱。

1. SQL字段记起来太费劲。例如查询语句“select ACC_ID, ACC_FIRST_NAME, ACC_LAST_NAME, ACC_EMAIL from ACCOUNT”,无论是字段还是表名都是db里面的字段和名字,而我们在程序中实际使用的是ORM到POJO的类名和属性名称,要一下子记住2套,非常没有必要。可以改造一下,和hibernate的hql语句类似,sql语句中的字段和表名允许直接使用属性名称和类名(Alias名也可以),ibatis在执行sql的时候自动换回来,这样多方便。

2. resultMap的映射规则不合理。假设我有一个表,10个属性,resultMap允许填写3个,任何查询语句使用这个resultMap必须包含这3个字段,否则报错;查询语句也可以包含更多其他的字段,不报错也不进行OR映射(也就是说select多余的字段除了浪费流量没有别的用处,这个很不合理)。合理的应该颠倒过来的,resultMap填写完整的映射(10个字段就有10个字段的映射),select等查询语句可以选择例如2个,选择几个就ORM几个,没有选择留默认值。这样一个类只需要定义一个resultMap就够了,查询语句需要什么字段自己选择,多方便。

3. ibatis的翻页支持纯粹就是瞎闹。我们可以做个简单的dialect,专门解决翻页的问题,不用所有的翻页select都自己定义Limit。。。之类的。

4. ibatis cache不好用。ibatis cache的对象序列化方法应该允许自定义,默认是Java默认的序列化,也应该允许选择别的;cache control加上一个memcached的支持。

我看到的就这4个,不知道进行改造有没有用处,还是我的理解不对。

   发表时间:2009-05-20  
那你就要hibernate好了!!!!


另外cache你完全可以提到ibatis的上层来!

0 请登录后投票
   发表时间:2009-05-20   最后修改:2009-05-20
luckaway 写道
那你就要hibernate好了!!!!


另外cache你完全可以提到ibatis的上层来!



1. 我觉得这是一种改进,又不是说hibernate就比ibatis好,只是ibatis有些地方的确感觉不方便,但是又可以做得更方便一点,我是这么认为的。

2. 那ibatis的cache设计岂不成了废物?一文不值了。我觉得他是可以改成更有用的cache的。

0 请登录后投票
   发表时间:2009-05-20  
看来2天, 就能总结出这些问题, 非常漂亮。 确实IBATIS这几个地方非常不爽。 很多年了。你第一个问题不是很赞同, IBATIS的本质是SQLMAPPING, 他需要保持对SQL的原始, 还有DBA也可以修改这个文件。


myreligion 写道
刚看了2天ibatis,感觉有些地方不太好用,准备改造一下,还请用的比较多的朋友指点下靠不靠谱。

1. SQL字段记起来太费劲。例如查询语句“select ACC_ID, ACC_FIRST_NAME, ACC_LAST_NAME, ACC_EMAIL from ACCOUNT”,无论是字段还是表名都是db里面的字段和名字,而我们在程序中实际使用的是ORM到POJO的类名和属性名称,要一下子记住2套,非常没有必要。可以改造一下,和hibernate的hql语句类似,sql语句中的字段和表名允许直接使用属性名称和类名(Alias名也可以),ibatis在执行sql的时候自动换回来,这样多方便。

2. resultMap的映射规则不合理。假设我有一个表,10个属性,resultMap允许填写3个,任何查询语句使用这个resultMap必须包含这3个字段,否则报错;查询语句也可以包含更多其他的字段,不报错也不进行OR映射(也就是说select多余的字段除了浪费流量没有别的用处,这个很不合理)。合理的应该颠倒过来的,resultMap填写完整的映射(10个字段就有10个字段的映射),select等查询语句可以选择例如2个,选择几个就ORM几个,没有选择留默认值。这样一个类只需要定义一个resultMap就够了,查询语句需要什么字段自己选择,多方便。

3. ibatis的翻页支持纯粹就是瞎闹。我们可以做个简单的dialect,专门解决翻页的问题,不用所有的翻页select都自己定义Limit。。。之类的。

4. ibatis cache不好用。ibatis cache的对象序列化方法应该允许自定义,默认是Java默认的序列化,也应该允许选择别的;cache control加上一个memcached的支持。

我看到的就这4个,不知道进行改造有没有用处,还是我的理解不对。


0 请登录后投票
   发表时间:2009-05-20  
ibatis cache 几乎相当于 hibernate的query cache。单纯匹配sql语句 意义不大。还不如自己针对需要做特定的cache效率还高些。
1 请登录后投票
   发表时间:2009-05-20   最后修改:2009-05-20
2.不好写单元测试,也不利于调试。而且也一张表对应多一个需要配置多个resultMap
的情况很少见,不知道你系统怎么设计的。就算一定要这样,如果你的系统其它发面的性能优化都已经做足够了,这点流量可以忽略不记的。至少慢查询比这个恐怖多了

3.第三问题,sdh5724已经说了。保持原始的SQL。如果你觉的在代码层不方便,你可以自己在封装一个。没必要什么事情都叫框架去做。

4.我觉的真的做大型网站,缓存不应该交给框架。跟框架配置在一起,有些事情你是控制不了的。用memcached这样分布式cache更应该要提到框架上层来,因为有有些数据通过hash分布式储存的。



框架更重要的应该是通用性,而不是为某个项目定制的!!!!
0 请登录后投票
   发表时间:2009-05-20   最后修改:2009-05-20
myreligion 写道
刚看了2天ibatis,感觉有些地方不太好用,准备改造一下,还请用的比较多的朋友指点下靠不靠谱。

1. SQL字段记起来太费劲。例如查询语句“select ACC_ID, ACC_FIRST_NAME, ACC_LAST_NAME, ACC_EMAIL from ACCOUNT”,无论是字段还是表名都是db里面的字段和名字,而我们在程序中实际使用的是ORM到POJO的类名和属性名称,要一下子记住2套,非常没有必要。可以改造一下,和hibernate的hql语句类似,sql语句中的字段和表名允许直接使用属性名称和类名(Alias名也可以),ibatis在执行sql的时候自动换回来,这样多方便。

2. resultMap的映射规则不合理。假设我有一个表,10个属性,resultMap允许填写3个,任何查询语句使用这个resultMap必须包含这3个字段,否则报错;查询语句也可以包含更多其他的字段,不报错也不进行OR映射(也就是说select多余的字段除了浪费流量没有别的用处,这个很不合理)。合理的应该颠倒过来的,resultMap填写完整的映射(10个字段就有10个字段的映射),select等查询语句可以选择例如2个,选择几个就ORM几个,没有选择留默认值。这样一个类只需要定义一个resultMap就够了,查询语句需要什么字段自己选择,多方便。

3. ibatis的翻页支持纯粹就是瞎闹。我们可以做个简单的dialect,专门解决翻页的问题,不用所有的翻页select都自己定义Limit。。。之类的。

4. ibatis cache不好用。ibatis cache的对象序列化方法应该允许自定义,默认是Java默认的序列化,也应该允许选择别的;cache control加上一个memcached的支持。

我看到的就这4个,不知道进行改造有没有用处,还是我的理解不对。


1.我写过代码生成器....没什么大用.不建议写
2.直接用bean或map....很少有人用resultMap传回数据的....除非你要自定义handle
3.分页写通用的sql片段......这样少很多很多代码...三个sql片段就够了
4.你可以用外部的cache.....这样都不用出sql句了
0 请登录后投票
   发表时间:2009-05-20   最后修改:2009-05-20
这里是对 ibatis 改造的结果:
http://nutz.googlecode.com
0 请登录后投票
   发表时间:2009-05-21  
zozoh 写道
这里是对 ibatis 改造的结果:
http://nutz.googlecode.com

做的挺不错,尤其Atom的事务使用想法感觉很有用,就是文档中废话多了点,也没看明白那个DAO是怎么回事,呵呵~~

我觉得数据库对象映射使用annotation是个错误的选择,很不利于维护,这个东西还是xml最可靠。

hibernate和ibatis搞的很大,是因为他们解决了很多问题,比如复杂的事务管理,比如存储过程支持,比如hql语句解析,但是他也有很多东西我们做一般web的用不到,就是纯成本了。我们也想弄个web基础框架,简单就好,真正高性能的web应用,框架没有必要干太多事情,我觉得nutz有些地方还是复杂了点。
0 请登录后投票
   发表时间:2009-05-21  
myreligion 写道
zozoh 写道
这里是对 ibatis 改造的结果:
http://nutz.googlecode.com

做的挺不错,尤其Atom的事务使用想法感觉很有用,就是文档中废话多了点,也没看明白那个DAO是怎么回事,呵呵~~

我觉得数据库对象映射使用annotation是个错误的选择,很不利于维护,这个东西还是xml最可靠。

hibernate和ibatis搞的很大,是因为他们解决了很多问题,比如复杂的事务管理,比如存储过程支持,比如hql语句解析,但是他也有很多东西我们做一般web的用不到,就是纯成本了。我们也想弄个web基础框架,简单就好,真正高性能的web应用,框架没有必要干太多事情,我觉得nutz有些地方还是复杂了点。


Nutz 要达到两个主要的目的是:

  1. 提供 SSH 的替代方案:所以提供了持久化层(Nutz.Dao)用来替代 iBatis | Hibernate, 提供了反转控制 (Nutz.Ioc) 用来替代 String-core, 提供了MVC框架(Nutz.Mvc)用来替代 Struts | Spring-MVC。 并且考虑到 JSON 在Web开发的重要性,提供了一个比 Goolge Gson 更小巧便捷的 Json 解析器(Nutz.Json)。
  2. 为了更好的延续使用者的知识经验, Nutz 允许你独立使用 Dao, Ioc, Mvc, Json。 就是说你可以在 Spring 中使用 Nutz.Dao, 你可以在 Nutz.Ioc 中使用 iBatis 或者 Hibernate 等等。

为了达到这两个目的,我写了那许多的代码,现在编译完的完整版已经有 400 多K了,我还会增加一些拦截器的实现,估计这个还得增加个10K,8K的。

现在 Nutz 还在 Alpha 阶段,在 Beta 以前,我可以随意的调整接口,所以很想听听你的意见,你觉得哪些功能是最不必要的,告诉我,这对我很有帮助。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics