现在的位置: 首页 > 综合 > 正文

谈谈NHibernate orm的局限性

2011年08月05日 ⁄ 综合 ⁄ 共 789字 ⁄ 字号 评论关闭

今日看了看NHibernate的一些应用实例,比较关注NHibernate的局限性,因为还没有深入的应用到自己的项目,只是简单参考了一些网上现成的使用范例,有些看法可能不一定对,欢迎大家能指出我的错误!

·应用xml配置文件,我可以方便的配置一个集合属性,并指定其对应的数据库表、筛选条件和排序方式,这很好,但是,一般的应用中往往有很多的select操作,筛选条件可能不确定,并且对同一条件,也很可能只需要取某一页的数据记录,对这种复杂而条件不确定的有比较频繁并且经常要分页支持的的select集合操作NHibernate下怎么很好的支持呢?

·对于更新和删除,如果只是更新删除单个对象,那么NHibernate的现有版本能不能很好的解决只更新修改了的字段的问题,如果对于同时更新删除不定数目的纪录,那么NHibernate又有什么好的解决方案呢?

·对于事务保护,NHibernate确实提供了方便的事务支持,但是,在许多情况下,许多事务处理我们希望对表现层调用方透明,当然可以在NHibernate上专门在包一层事务层来专做这件事,但是,如果事务中涉及批处理和上一节提到的同时更新删除多记录和不定数目字段的情况,是不是都只有实例化每个对象来做呢?这样做的话,它的效率又怎么保证呢?

·再有就是NHibernate用xml配置文件来保存or映射关系,我还没仔细看他的具体实现,直观上猜想,大方向上对这种配置文件我们有两种反方法来应用:一直是用反射,动态解析配置文件从而动态的构造sql来操作数据库;二是采用代码生成,事先,或者,在第一次运行或调用时(对用户透明或不透明均可)在开发端或者在内存中进行编译,根据配置文件生成相应的映射操作的具体实现类,再有这样的类库代码来完成具体的数据库操作,后者效率要高一些,我还没深入研究NHibernate是怎么做的,估计还使用反射加充分的缓存吧?

抱歉!评论已关闭.