浅论hibernate与mybatis框架

       在做逻辑的推演时，首先我们要确定一个准确无误的、一般性的原则作为前提。只有保证这个前提是绝对的、无差别的，才能够证明结论是正确的，整个逻辑的论证才是可信的。因此无论任何科学，找到一个绝对的、一般性的指导原则是迫切和必须的。没有这个原则，一切研究将是毫无意义的。就像斯威夫特在他的《格列佛游记》中讽刺的那样：“他们终其一生在进行研究，研究从黄瓜中提取阳光，将大便还原为食物”。我们的时代也不断在进行这样的研究，研究用水来代替石油，去太空中寻找反物质。这些研究无疑都取得了巨大的成功，获得了大量的经费，堪称骗术界的楷模与典范。但也仅此而已，这种成功是时代的成功，而非历史的成功。历史终将剔除一切虚妄的东西，回归真实。“我从这里开始；因为我将重新回到这里。”——巴门尼德《论自然》

        一切科学都是有一个确定无误的前提的，例如几何学研究物质的形状，点的概念构成了整个几何学的基础；数学研究物质的量，它的理论基础实际上是建立在差异性上的，也就是说，承认每一个都是一，而不是多。只有这样再做四则运算时，1+1才会等于2。计算机科学当然有它的特殊性：我们研究的东西并非是自在的存在着，而是人类思维的产物，是人类生产力发展的产物。甚至可以说，它更像是一门技术，而非科学。它的存在是为了解决人类事务中的一些问题，因此也会受到人类事务的一般规则的约束。在这门学科不断的发展中，它尝试着模拟现实世界，从机器语言一直到现在的高级计算机语言，它更加表现出科学的性质。我们现在所了解的设计模式、一些设计原则，全部是建立在高等计算机语言上的。java语言毫无疑问是比较优秀的计算机语言之一，它的面向对象的设计思想使我们可以研发出可以轻松处理复杂事务软件。它将现实世界中抽象的、一般的行为描述为类，而将某个类特殊的实例称之为对象。就像现实世界中有“人”的抽象的概念，而张三这个具体的人则是“人”这个类的具体实现。java的设计思想继承了C、C++。继承在英文中叫做extends，有继承和扩展的意思，与中文中的继承有着很大的不同，更多的表现为扩展。也就是说java扬弃了C++的某些东西，而成为现在的语言。

        hibernate尝试在这一点上走的更远，它提出并实践了ORM（对象关系映射）这一思想，试图将所有的问题描述为类和对象的关系。这是有很积极意义的。hibernate的思想得以实现，很大程度上依赖于JDK的反射技术。通过反射、XML解析、注解，它可以很容易的将数据库表映射为一个对象，并且通过标记对象的状态来判断对象的行为（框架的技术细节不在该篇进行讨论）。hibernate旨在提供给开发人员一个标准的、简易的开发模式，使程序员不必过多的关心SQL——有人会对这一点提出异议吗？使用简易并且标准化，这其实是每一个框架的设计初衷。如果必须要大费周折写出一段执行简单功能的代码，才能够显示出个人技术的高深莫测，我们何不自己封装JDBC？

        现在回到最初讨论的话题上来：我们要找出框架设计的原则，符合这一原则的我们就认为是好的，否则无论这个框架的实现原理有多么复杂，使用起来有多么困难，也不应该认为是一个良好的框架。

        java持久层操作最原始的是基于JDBC的操作，它提供了java程序与数据库的连接。JDBC的操作步骤大致如下：

        一、使用Class.forName("Driver Name")装载驱动。

        二、使用Connection con = DriverManager.getConnection(url, "username", "password");指

                定数据库连接地址、用户名和密码建立一个连接对象。

        三、使用Statement stmt = con.createStatement();创建一个statement对象用来执行sql。

        四、ResultSet rs = stmt.executeQuery（"SELECT column FROM table"）；使用statement

                获取结果集，并最终封装成java对象。

这些操作步骤固定，而且需要编写大量业务无关的代码，才能够获取到数据。而且sql与java代码耦合在一起，每次要对返回数据做单独的复杂处理。这样在以后程序扩展起来会变得非常麻烦，hibernate和mybatis就是用来解决这些问题的，但是在处理问题的思想上二者有着不同，hibernate意在对持久化操作进行一个完整的封装，程序员可以通过java语言就可以操作数据库，而不必关注sql的实现。而mybatis则保留了sql自定义的功能，仅对JDBC一些通用的步骤进行了封装。二者在持久层实现上各有千秋，但我认为mybatis的这一做法在现阶段是很符合实际的一些需求的。

        首先，hibernate的封装过于严重，开发人员完全不知道sql的具体实现，因此无法对于sql进行优化。当然，这也是hibernate设计的初衷——开发人员无须关注sql的实现。但是对于一些复杂的需求，需要关联多张表并且进行复杂查询的，hibernate就显得力不从心了，有时候我们又不得不自定义一些本地sql去实现功能。也许有反对者会说：那是hibernate的学习成本较高，而我们对于hibernate的了解又不够深。但是一个成熟的技术是无须开发人员进行揣测的，如果hibernate有一些可行的解决方案，大可以在官网上进行声明。再说，哪一个使用hibernate的大牛，在项目中没有使用过本地sql呢？而且，既然hibernate的使用成本如此高、使用起来又如此复杂，显然违背了框架设计的初衷。说一样技术因为使用复杂，所以用起来才能够简单高效，简直是不可思议！

        其次，有时候一些需求并非需要某张表所有的字段，比如在做用户登录认证的时候，我们仅需要用户名密码即足够了。但由于hibernate的完全对象映射，我们不得已要查询出所有的字段。这就好像要去一个商店买东西，本来仅仅需要买一瓶饮料就好了，但却不得已搬来了整个商店！在单表操作，或者表关联不是很多的情况下，还能够接受。但如果关联的表很多，且表中的字段也非常多呢？这样肯定很大程度上会影响性能的。

        当然，在业务简单，项目比较小时，hibernate还是具有明显的优势的。而且，hibernate遇到的所有这些问题，都不应该去进行掩饰的，而是值得我们进行思考的。就像我们期望出现一种计算机语言，它更加接近人类的语言，我们无需做更多的事就可以完成复杂的功能。这种想法可以当做一种理想，如果要实现它则需要付出更多的心血去完成。