iBATIS评价

我想，这里主要的分歧在于，哪些逻辑应该放在数据库中，哪些逻辑在应用程序中。
我的立场是，除了少量的存储过程以外，类似于触发器、默认值之类的东西以及绝大部分的存储过程实现的功能，都应当由程序这一端来控制，而且，是体现在业务逻辑中(不是在ibatis这一层)。像默认值这类东西，就像各位说得那样，是客户的业务决策，那么，为什么要把业务决策的东西放在数据库或者ORM层中，而不是放在业务模型那一层？仅仅因为方便？此时，即便是让数据表中的某个字段为null，也是业务模型"刻意"使它为null，而不是不touch就是null.
在这种策略下，默认值或者null和ibatis并没有太大关系。
关于int值的null和默认情况，我觉得有必要再深入思考一下，它与类似于String在概念上并没有区别,这只是可以java对于性能的一种妥协。如果纯粹OO的话，用Integer来取代，此时，null与非null就会有本质的区别。不能说因为是数值型，就没有null的可能性了，否则，也只能说所使用的工具或者方法制约了概念的建模方式。

我以前看过hibernate的文档，感觉它不合适我的需求。
在开发mis中，在实施维护的时候，经常需要增加字段，字缎的数据类型也会修改，如果用hibernate就需要修改代码了。
还有一点就是，mis系统中，在一个列表界面需要很多张表，例如：
销售单里 需要零件，客户，价格，部门，等等，如果用hibernate，
如a.getb.getXX()，对象b的所有字段都从数据库读取出来，那么性能就很差了
。也许通过继承来解决这个问题，但是这样带来的问题也就更多了。

iBatis还有一个在做一对多关系查询时出现的N+1的效率问题，不知道各位有什么好的解决方法？

数据类型都改变了，你用iBATIS一样要改代码，这就是理由？


你还不懂HQL。

用hibernate你也不用每次都返回一个对象吧？再仔细研究一下hibernate吧。

TSS: Using Hibernate3 as a JDBC framework
http://www.theserverside.com/blogs/showblog.tss?id=Hibernate3_JDBC

最近简单看了一下iBatis，我找不到有什么理由要去用它。要说方便的话，好象也不比Hibernate方便。Hibernate在XDoclet的支持下，维护NamedQuery只需要改Java文件就行了；iBatis还得改配置文件呢。

我觉得iBATIS比较适合老系统改造工程
不过的确用起来有点麻烦

如果数据类型改了,为什么一定要改代码?
我只要修改配置文件就可以了,数据我放在HashMap.
增加字段也可以这样,修改配置就可以了.

问题是我不想改代码.

我看过hibernate文档,当时javaeye还没有成立,hibernate还没有中文文档,网上资料很少.我看hql总是有点不喜欢,特别是设计一个综合查询的时候,(where 后的字段不确定).用hql有点麻烦了.