Hibernate学习-------------传统数据层问题以及数据层开发

关于Hibernate的学习记录：

一、传统数据层的开发问题分析
Hibernate中文翻译为“冬眠”，在开发上Hibernate的主要功能是进行数据层的操作实现
在任何一个项目开发之中，一定共需要存在有四个层：
**显示层：
  |-动态语言：JSP，如果要想合理的实现需要编写一堆的Scriptlet代码，而后利用EL+JSTL解决了
  |-静态语言：HTML、JavaScript，可以完成所有的开发，但是DOM的难度太高，利用iQuery解决
**控制层：核心应用在于数据验证、业务调用、分法处理，利用Struts可以解决控制层的问题
**业务层：事务控制、数据层调用，待解决问题；
**数据层：数据层里面只能够编写JDBC代码，JDBC太重复了；
现在有一个工具可以帮助自动的根据指定的原则动态配置SQL，动态执行SQL，那么这样的数据层开发就很舒服了。那么这个时候我们的处理方式只能够想到反射，但是同时带来的问题是难度太高了。
另外一点，在开发之中，有可能会根据客户的使用习惯选择&配置数据库，但是按照传统的开发，数据库代码很麻烦，至少每一个数据库支持的SQL语句形式不同，就拿一个最简单的分页操作：
**Oracle、DB：ROWNUM
**MySQL：LIMIT
**SQL Server：TOP

传统开发：使用的结构固定、不易于扩展操作，同时编写的代码重复，设计困难，这些都属于JDBC直接开发的完全弊病


二、数据层开发之道
这样一种解决方案：
如果现在要进行数据库的开发，那么一定使用的只能够是JDBC，但是如果直接使用JDBC，其缺点是代码重复、设计性差，那么可以想办法针对于JDBC的操作做一个装饰，让其变得更加容易一些

数据层
                   ---->   数据层工具类   ----> JDBC  ----->数据库
简单java类

解决的问题关键在于数据层不要直接与JDBC耦合，数据层不应该关心JDBC的存在，中间的工具类帮助用户关心JDBC
随着开发历史的加长，出现了许多的数据层工具类
1、JDO（Java Data Object,java数据对象）：是最早的提供数据库操作的工具类，但是这个工具类也只是简单利用了反射进行了操作的自动生成而已，支持的操作很有限，现在已经不再使用了
2、EJB 2.x Entity Bean(实体企业JavaBean)：是真正的第一款官方提供的“ORMapping”框架（Object-Relation Mapping，对象关系映射），在EJB上真正实现了数据库间的完全可移植性。可是最早的EJB 2.x不支持分页，所有的数据库的数据如果加载到内存，就一直保存着，于是造成一个最大的问题-----没人用的起。
    |--它来到世间，给世界留下了宝贵的财富------理论价值，EJB使用了实体对象(简单java )直接进行操作，调用类中的setter()方法时会自动进行数据库的更新操作，同时第一次官方强调了数据层的开发标准，用户完全不需要知道JDBC的存在，操作对象的时候就自动进行数据库操作
3、Hibernate：是真正第一款在世界流行的实体层开发框架，在EJB 2.x的完美熏陶下，解决了EJB 2.x中的种种性能问题以及使用局限（EJB必须要有EJB容器支持，而Hibernate只需要WEB），很多的大型项目都是用Hibernate开发，并且一直延续到今天，可是它的问题只有一个：Hibernate起源于EJB技术，所以其性能的处理上不高（考虑太多）
4、EJB 3.x：此技术解决了之前所有EJB的缺点，并且加强了优点，但是缺点是依然需要EJB容器的支持，所以也没有人使用了，EJB 3.x的设计者也是Hibernate的设计者
5、MyBatis（前身：IBatis）：EJB和Hibernate考虑了数据库的可移植性，封装了所有可能见到的数据库操作，但是大部分情况下，我们可能需要的只是一个简单的框架（自动设置内容、数据转型，并且不需要数据库可移植性）；
以上的而技术都属于ORMapping技术，但是千万记住一点：JDBC也是一个ORMapping的开发框架，ORMapping的一个特点：对象的改变可以引起数据库的变化（随着发展也不是特别明显了）

总结：Hibernate可以解决的是数据层的开发问题以及数据库的可移植性操作问题