沉重的负担-Hibernate的反模式

前言 虽然Hibernate作为最早流行的轻量级ORM，java社区的头号杀手应用，给数据库软件开发带来极大的便利和影响，但是在长期的实践中，仍觉得有些场景比较笨重，使用起来不甚顺手，遂发发牢骚。 虽然本人有能力解决这些问题，也提到了以前开源的扩展模块，但并非刻意宣传，因为对第3个模式的不满致使我决定放缓对hibernate的修改，除非有外力支持，比如所在公司支持或者网友支持。 题外话，我正在抽空写以COM、XPCOM为基础的orm，语言是C++。COM可以实现反射功能，恰好用来写ORM，成品可以供支持COM的开发工具使用，也可以在js中使用，js中的orm不是梦想，当然各大论坛有些网友说用纯js写orm也是个可行的办法，确实值得一试，不过访问数据库的组件还是得用c/c++之类的来写，这个跑不掉。 反模式1：不支持模块化配置文件 问题场景1： 当多个开发人员同时将几百个mapping标签写到hibernate.cfg.xml里面，而且还在不断增加的时候，文件冲突就是家常便饭。 建议解决方案： 直接修改hibernate，2年前俺在hbn-dyn-mod的第2个功能就这么做来着，但是经常加班加到熊猫样，还是业余时间搞的，又没有得到领导的支持，而且hbn-dyn-mod第1个功能开源后没什么人反响，所以连在sourceforge上更新的热情都没了，最后，连硬盘里的代码都丢失了... 问题场景2： Hibernate.cfg.xml经常改动，在cvs,svn经常update，如果数据库名称和密码不同，可有得受了... 建议解决方案： 手工改改。 或者先读取hibernate.cfg.xml到内存中，从其他文件获取本机的数据库名和密码，并修改到内存中的hibernate.cfg.xml，然后再用修改后的内容启动Configuration，这样一劳永逸。 反模式2：不支持延迟加载映射文件 本来某段时间只专注一个模块的开发，但是做个单元测试也要等全部xxx个映射文件加载完毕，时间和内存消耗让本就不多的系统资源捉襟见肘，他就没有选项支持直到调用Session.get, load, save, createQuery.list等api时才读取对应的.hbm.xml吗？这也就算了，要是其他模块的开发者上传了一个错误的.hbm.xml或者持久化类，那就连运行都免了... 建议解决方案： 暂时屏蔽出错的模块对应的Mapping标签。 另外Hibernate2的话，可以试试hbn-dyn-mod。 反模式3：两套DOM模型 Org.hibernate.mapping包里的类，在Configuration里使用，可以完整的对应.hbm.xml里所有的信息，到了SessionFactory，就只能拿到org.hibernate.metadata.ClassMetaData了，其他几个模型类分散到其他包里，而且还不提供SessionFactory.getConfiguration方法，也太绝了点吧... 而且ClassMetaData的用法我实在搞不懂，也懒得研究。 建议解决方案： 懒得想，直接修改源码，给SessionFactory添加getConfiguration方法。 反模式4：不支持动态重载映射文件和持久化类 这个要求高了点，见仁见智了，由于jvm的局限性，估计有些人因此而转向了更灵活的python或ruby。当然，我可以解决这个问题，8过正如开头所说的原因，现在对修改hibernate没兴趣。