Kela's Blog

        Hibernate有那么多的优点，那么这些优点在我们的应用开发中是如何体现呢，确切的说我们不是因为他流行而用它而是因为它能给我们的开发带来帮助，能提高系统的性能。
        Hibernate是持久层的框架，那就的先从持久层说起。看看我们通常的持久层是如何做的。
        1. 关于持久层的介绍：
        MVC作为主流的系统架构模式，已被越来越多的开发者所使用。MVC中的M，也就是Model则包含着大量的业务逻辑和数据逻辑，持久层作为Model中的重要组成，其设计的优劣将对系统的整体表现产生至关重要的影响。
       “持久层”，也就是在系统逻辑层面上，专注于实现数据持久化（对内存的数据进行固化，通常指保存至住据库）的一个相对独立的领域。也就意味着，我们的系统架构中，因该有一个相对独立的逻辑层面，专注于数据持久化逻辑的实现，与系统其他部门相对而言，这个层面应该拥有一个较为清晰和严格的逻辑边界。
        2. 持久层的设计
        场景：（在“深入浅出Hibernate”中一个非常好的例子），用户进入网上商店进行购物结算，那么他有以下的业务处理逻辑。
            1）根据客户ID取出客户当前等级（如，普通会员，VIP）
            2）根据客户等级获得打折比率。
            3）根据总金额 × 打着比率计算到实际支付的金额。
            4）将本次实际的支付的金额累积到客户累计消费金额的字段中。
            5）返回实际金额。
        A方法，有的朋友可能这样处理：
          public calss NetShop {
               ......

               /*
                * 购物结算
                */
                public BigDecimal balance(String userID) {
                      conn = ......
                      try {
                            //获取当前等级， select
                            ......
                     } catch () { }
                     try {
                          //获得打折比率， select
                          //计算实际支付金额
                          ......
                    } catch () { }

                   try {
                        //将支付的金额累计到累积消费中， update
                        //修改客户现有的余额
                        ......
                  } catch () {}

                  //返回实际的消费金额
                  return new BigDecimal(****);
             }
         }
         B. 那另外的一些朋友他们会说，在A里面混杂的业务逻辑和数据访问代码极大的干扰了阅读程序的人，而且这样的代码将给日后的维护带来极大的困难（我也是这样认为哦 ~ ~）。如果我们的实际应用当中的业务逻辑变得非常庞大和复杂的时候，A的做法显然有忧缺点的。于是，就有了下面的改造：
         public calss NetShop {
              ......

              /*
               * 购物结算
               */
             public BigDecimal balance(String userID) {
                A a = new A();
                String gradeStr = null;  //客户级别
                long agioLong = 0.0;

               //获取当前等级
               gradeStr = a.getUserGarde(userID);

               //根据等级计算打折比率
               agioLong = a.getAgio(gradeStr);

               //累计客户消费金额
               a.updateCustMoney(userID, agioLong);

               //修改客户余额
               a.updateUserBalance(userID, agioLong);
        
              //返回消费金额
              return new BigDecimal(****);

            }
         }

          public class A {
               //去实现上面对方法
          }
          可以说B的实现方式，是我（呵呵，大多数可不敢乱说）经常使用的方式，在实际的应用当中结合一些数据库性能上的优化（连接池，预编译语句之类的），基本上已经实现了，业务和数据层的分离。
          然而，在现在客户的应用需求和公司考虑可重用等因素的影响下，我们有不得不去考虑，我们的应用能不能实现严格意义上的跨数据库使用，或者说，我们的应用从一个数据迁移到另外一个数据的时候，是不是只做很少的改动（因为，现在有很多的项目需要引入第三方的产品，它山之石可以攻玉嘛）。带着这样的疑问，那我们是不是会写很多的基于特定数据库的数据层处理代码（当然了，这也是个好办法）。现在我们就要引入Hibernate了，我觉得选择一个比我们自己的实现方式更好的实现方式，是一个更加聪明的决策。那么Hibernate能干什么？
           1）减少乏味的代码
                无论是A方法还是B方法我们都少不了大量的数据库连接，查询，关闭等代码，写得多了也就觉得烦了，Hibernate封装了数据库持久层大多数技术细节，如事物管理，连接管理，sql执行等。
                至少这点，我们是需要的。
           2）更加面向对象的设计
                 就是说像设计对象一样的去设计和操作数据库。这条可能现在还不能理解。
           3）更好的性能
                  我觉得这条好理解多了，系出名门和专家之手的框架，肯定提供了非常优秀的性能优化机制。比如，对连接池，PreparedSatatement 缓存，数据缓存等。这点我们可以大可放心，因为使用者决定了它的优秀。
            4）更好的移植性
                   我们只需要简单得修改其的配置参数，即可实现底层数据库的良好切换（这也是有前提的哦，可不能使用特定数据库都有的特性）。这条的好处是显而易见的。

            关于引入Hibernate有什么好处，我觉得以上就足够了，它确实能帮助我们。