现有一些ORM工具的弊端

　　作者：Aargan　　　
　　　　
　　现在流行很多ORM工具,其中HIBERNATE算做得很好的了,使用的人群也非常多,而且大做都在说好,为什么讷?使用简单,开发比较快速,但是问题也随之而来了....
　　
　　* 本文假设开发的都是和数据库相关的项目
　　
　　ORM能做什么?帮你用对象的方式来操作RDBMS,这是很多人渴望的,因为他不再需要关心底层数据库是怎么工作的了,甚至不需要知道数据库的结构,一切都交给ORM去治理了,看起来是非常好的,程序非常直观,写起来也轻易,但是运行起来呢?
　　
　　事实上,开发者使用ORM工具时,最痛苦的也许就是DBA了,作为DBA,要保证整个系统的性能,必需对一些运行不好的SQL进行TUNING,做一些优化,调整其执行计划,是整个应用的性能及稳定性提高,但是当他们发现有SQL性能不好,需要找程序员协调修改时,得到的回答是:"我们使用xxx (某ORM工具),SQL都是他生成出来的,我没办法调整",ft,你不调整,难道我来啊?最终结果呢,程序跑不动,该改得还是得改,管你用什么xxx, 这时候也许就会觉得痛苦了吧?
　　
　　原来ORM并没那么好用?SURE,object的世界和relational的世界本来就不能很好的映射,就不要要求他那么完美了吧!
　　
　　那要么我就就用原始的SQL语句,在程序里直接用JDBC操作,这总不会有什么限制了吧,是的,你用SQL语句能做的东西你都能做,但是怎么做讷?
　　
　　Connection conn = null;
　　Statement stmt = null;
　　ResultSet rs = null;
　　log.info("==SQL==:" + sql);
　　
　　try {
　　conn = getDataSource().getConnection();
　　stmt = conn.createStatement();
　　rs = stmt.executeQuery(sql);
　　return readSingleObjectFromResultSet(rs);
　　} finally {
　　close(rs, stmt, conn);
　　}
　　
　　ft,大哥,太麻烦了吧,每查这么一次就要写这么多东西啊,我真的只需要执行语句SQL语句而已啊,
　　
　　是的,你只需要执行易于SQL语句,但是你必需这么做
　　
　　不管怎么,麻烦是麻烦了,但总能工作了吧,返回结果呢?ResultSet,我不觉得他很合适,Connection一关了他就不能用了,要是不关讷,等我用完了再关,(不是吧,那是Connection讷,很金贵的,HINT:对于"珍贵"的资源在真正需要时才使用,而且用完了马上释放掉,谁让他那么宝贵讷),于是,在读出数据之前,现把结果拿出来,关掉Connection,返回,这里可以做一些工作,让你的ResultSet里取得的数据返回得更漂亮一些,做一些映射,放到一些简单的bean里返回给上层使用
　　
　　相比之下,大多数人都选择ORM和JDBC结合使用的办法,简单的CRUD操作,就让ORM去做吧,简单,省心,开发效率高,的确是这样,其他的工作讷, 不要勉强你的ORM工具,也不要说他不够完美,事实就是这样,OBJECT 和 RELATIONAL本来就不是一样的东西,哪能那么完美的映射讷?
　　
　　那我们就这么用吧,但是问题又来了,你写在程序里的SQL,;尽管是少数,但这些都是比较复杂的了(不是么?),运行了一段时间,DBA又来找了:
　　
　　那个谁谁谁,你的这个SQL需要搞一下,要加个HINT,调整一下执行计划,否则数据库的COST太大了
　　
　　不是吧?又要改?(怎么说又?难道不是么,改的还少了?)
　　
　　于是就修改,编译,打包,测试,发布.........DBA又来了....(怕怕)
　　
　　于是就有了iBATIS,他是一个什么东西呢?基本上,他有两部分内容:SQL map 和 DAO.
　　SQL map是核心的内容,负责将你某一次操作影射到一个SQL语句上去执行,当然,这个SQL语句是可以预见并且非常灵活且轻易调整的,DAO是一个上层一点的封装,目的是为了让整个应用更加灵活,自由
　　
　　使用iBATIS最大的诱惑就是,系统运行的所有SQL语句,你都可以在程序以外进行调整,功能上的可以开发者来做,性能上的么,把你的配置文件给DBA,他会给你做好的,很轻松,不是么?