随着项目的进展，Castle和IBatisNet给我的惊喜更多。Com+很重，不需要分布式的中小项目慎用，NHibernate虽好，NHibernate的2005－9－20发布了最新版本1.0-rc1，缺少高水平的OO设计师，项目组程序员水平参次不齐 ，应用Castle + IBatisnet大家不会再把精力浪费到数据访问，事务处理，主键生成等地方了,可以集中精力进行业务组件的编写。项目的进展很顺利。
随着项目的进展，Castle和IBatisNet给我的惊喜更多。Com+很重，不需要分布式的中小项目慎用，NHibernate虽好，NHibernate的2005－9－20发布了最新版本1.0-rc1，缺少高水平的OO设计师，项目组程序员水平参次不齐 ，应用Castle + IBatisnet大家不会再把精力浪费到数据访问，事务处理，主键生成等地方了,可以集中精力进行业务组件的编写。项目的进展很顺利。
从架构上讲，Castle作为轻量级Ioc容器无疑要位于高位，所以iBatisNet现在只需要致力于完成持久层的sql-object映射工作，其他的事就由Castle来装配好了。
iBatisNet中的DaoManager作的两大工作：dao事务管理，dao接口与实现的解藕，Castle的事务处理使用了是Castle的扩展单元,可以配置到方法级，用法类似于Com+，需要对该类设置声明性事务属性以确定其事务性行为。指定哪些类的哪些方法需要事务处理，不管你是dao还是service,通通可以自由地在这儿指定，根本不会侵入你所写的类，如果是Com+的话，会强迫你去实现Com+的ServicedComponent。
IbatisNet的缓存非常不错，我们需要用好它了。在IbatisNet中，cacheModelsEnabled默认是true的，别忘了在写具体的po.xml时，作缓存有关的配置工作。不过具体用哪一种(MEMORY LUR FIFO OSCACHE)容量设多大，都得根据项目的实际情况来定，我通常首选LUR。正确设定缓存的Flush语句，杜绝缓存中脏数据产生的可能。缓存使用前提是，系统中对表的读写一定要都通过ibatisNet来进行，也就是封闭的。
动态SQL的确是个强点。熟悉后感觉很不错。IBatisNet中所有的DAO方法都只传一个值对象，复杂查询当然也不例外。
