精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-05-20
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个,不知道进行改造有没有用处,还是我的理解不对。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-05-20
那你就要hibernate好了!!!!
另外cache你完全可以提到ibatis的上层来! |
|
返回顶楼 | |
发表时间:2009-05-20
最后修改:2009-05-20
luckaway 写道 那你就要hibernate好了!!!!
另外cache你完全可以提到ibatis的上层来! 1. 我觉得这是一种改进,又不是说hibernate就比ibatis好,只是ibatis有些地方的确感觉不方便,但是又可以做得更方便一点,我是这么认为的。 2. 那ibatis的cache设计岂不成了废物?一文不值了。我觉得他是可以改成更有用的cache的。 |
|
返回顶楼 | |
发表时间: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个,不知道进行改造有没有用处,还是我的理解不对。 |
|
返回顶楼 | |
发表时间:2009-05-20
ibatis cache 几乎相当于 hibernate的query cache。单纯匹配sql语句 意义不大。还不如自己针对需要做特定的cache效率还高些。
|
|
返回顶楼 | |
发表时间:2009-05-20
最后修改:2009-05-20
2.不好写单元测试,也不利于调试。而且也一张表对应多一个需要配置多个resultMap
的情况很少见,不知道你系统怎么设计的。就算一定要这样,如果你的系统其它发面的性能优化都已经做足够了,这点流量可以忽略不记的。至少慢查询比这个恐怖多了 3.第三问题,sdh5724已经说了。保持原始的SQL。如果你觉的在代码层不方便,你可以自己在封装一个。没必要什么事情都叫框架去做。 4.我觉的真的做大型网站,缓存不应该交给框架。跟框架配置在一起,有些事情你是控制不了的。用memcached这样分布式cache更应该要提到框架上层来,因为有有些数据通过hash分布式储存的。 框架更重要的应该是通用性,而不是为某个项目定制的!!!! |
|
返回顶楼 | |
发表时间: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句了 |
|
返回顶楼 | |
发表时间:2009-05-20
最后修改:2009-05-20
这里是对 ibatis 改造的结果:
http://nutz.googlecode.com |
|
返回顶楼 | |
发表时间:2009-05-21
zozoh 写道 这里是对 ibatis 改造的结果:
http://nutz.googlecode.com 做的挺不错,尤其Atom的事务使用想法感觉很有用,就是文档中废话多了点,也没看明白那个DAO是怎么回事,呵呵~~ 我觉得数据库对象映射使用annotation是个错误的选择,很不利于维护,这个东西还是xml最可靠。 hibernate和ibatis搞的很大,是因为他们解决了很多问题,比如复杂的事务管理,比如存储过程支持,比如hql语句解析,但是他也有很多东西我们做一般web的用不到,就是纯成本了。我们也想弄个web基础框架,简单就好,真正高性能的web应用,框架没有必要干太多事情,我觉得nutz有些地方还是复杂了点。 |
|
返回顶楼 | |
发表时间:2009-05-21
myreligion 写道 zozoh 写道 这里是对 ibatis 改造的结果:
http://nutz.googlecode.com 做的挺不错,尤其Atom的事务使用想法感觉很有用,就是文档中废话多了点,也没看明白那个DAO是怎么回事,呵呵~~ 我觉得数据库对象映射使用annotation是个错误的选择,很不利于维护,这个东西还是xml最可靠。 hibernate和ibatis搞的很大,是因为他们解决了很多问题,比如复杂的事务管理,比如存储过程支持,比如hql语句解析,但是他也有很多东西我们做一般web的用不到,就是纯成本了。我们也想弄个web基础框架,简单就好,真正高性能的web应用,框架没有必要干太多事情,我觉得nutz有些地方还是复杂了点。 Nutz 要达到两个主要的目的是:
为了达到这两个目的,我写了那许多的代码,现在编译完的完整版已经有 400 多K了,我还会增加一些拦截器的实现,估计这个还得增加个10K,8K的。 现在 Nutz 还在 Alpha 阶段,在 Beta 以前,我可以随意的调整接口,所以很想听听你的意见,你觉得哪些功能是最不必要的,告诉我,这对我很有帮助。 |
|
返回顶楼 | |