Hibernate源代码包简要介绍
net.sf.hibernate.*
该包的类基本上都是接口类和异常类
net.sf.hibernate.cache.*
JCS的实现类
net.sf.hibernate.cfg.*
配置文件读取类
net.sf.hibernate.collection.*
Hibernate集合接口实现类，例如List，Set，Bag等等，Hibernate之所以要自行编写集合接口实现类是为了支持lazy loading
net.sf.hibernate.connection.*
几个数据库连接池的Provider
net.sf.hibernate.dialect.*
支持多种数据库特性，每个Dialect实现类代表一种数据库，描述了该数据库支持的数据类型和其它特点，例如是否有AutoIncrement，是否有Sequence，是否有分页sql等等
net.sf.hibernate.eg.*
Hibernate文档中用到的例子
net.sf.hibernate.engine.*
这个包的类作用比较散
net.sf.hibernate.expression.*
HQL支持的表达式
net.sf.hibernate.hq.*
HQL实现
net.sf.hibernate.id.*
ID生成器
net.sf.hibernate.impl.*
最核心的包，一些重要接口的实现类，如果Session，SessionFactory，Query等
net.sf.hibernate.jca.*
JCA支持，把Session包装为支持JCA的接口实现类
net.sf.hibernate.jmx.*
我不懂JMX，只知道JMX是用来编写App Server的管理程序的，大概是JMX部分接口的实现，使得App Server可以通过JMX接口管理Hibernate
net.sf.hibernate.loader.*
也是很核心的包，主要是生成sql语句的
net.sf.hibernate.lob.*
Blob和Clob支持
net.sf.hibernate.mapping.*
hbm文件的属性实现
net.sf.hibernate.metadata.*
PO的Meta实现
net.sf.hibernate.odmg.*
ODMG是一个ORM标准，这个包是ODMG标准的实现类
net.sf.hibernate.persister.*
核心包，实现持久对象和表之间的映射
net.sf.hibernate.proxy.*
Proxy和Lazy Loading支持
net.sf.hibernate.ps.*
该包是PreparedStatment Cache
net.sf.hibernate.sql.*
生成JDBC sql语句的包
net.sf.hibernate.test.*
测试类，你可以用junit来测试Hibernate
net.sf.hibernate.tool.hbm2ddl.*
用hbm配置文件生成DDL
net.sf.hibernate.transaction.*
Hibernate Transaction实现类
net.sf.hibernate.type.*
Hibernate中定义的持久对象的属性的数据类型
net.sf.hibernate.util.*
一些工具类，作用比较散
net.sf.hibernate.xml.*
XML数据绑定
Hibernate入门 - 基础配置
Hibernate配置文件可以有两种格式，一种是hibernate.properties，另一种是hibernate.cfg.xml。后者稍微方便一些，当增加hbm映射文件的时候，可以直接在hibernate.cfg.xml里面增加，不必像hibernate.properties必须在初始化代码中加入。但不管怎么说，两种的配置项都是一样的，下面详细介绍：
在Hibernate的src目录下有一个hibernate.properties模板，我们不必自己从头写，修改模板就可以了
| java代码: |
|
hibernate.query.substitutions true 1, false 0, yes 'Y', no 'N'
|
这个配置意思是当你在Hibernate里面输入true的时候，Hibernate会转化为0插入数据库，当你在Hibernate里面输入false的时候，Hibernate会转化为1插入数据库，后面的Y，N同理。对于某些数据库，例如Oracle来说，没有boolean数据类型，就是采用1代表true，0代表false，因此使用这个配置在Hibernate里面直接用true/false会非常直观。
| java代码: |
|
hibernate.dialect net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.driver_class org.gjt.mm.mysql.Driver
hibernate.connection.driver_class com.mysql.jdbc.Driver
hibernate.connection.url jdbc:mysql:///test
hibernate.connection.username root
hibernate.connection.password
|
这是一个连接MySQL数据库的例子，很直观，不必解释，不同的数据库的连接参数模板中全部给出了。
| java代码: |
|
hibernate.connection.pool_size 1
hibernate.statement_cache.size 25
|
这是Hibernate自带的连接池的配置参数，在默认情况下将采用。意义很直观，不多解释。只是提醒一点，Hibernate这个连接池是非常原始非常简单的连接池，如果你在项目中用Hibernate的话，建议你首选App Server的连接池，次选Hibernate带的DBCP连接池。自带的连接池应该做为末选。
如果你采用DBCP连接池，除了要配置DBCP连接池以外，还需要取消掉下行的注释：
| java代码: |
|
hibernate.connection.provider_class net.sf.hibernate.connection.DBCPConnectionProvider
|
其它的连接池同理。
如果采用App Server的连接池，假设App Server连接池的DataSource的JNDI名称为"mypool"的话，配置应该如下：
| java代码: |
|
hibernate.dialect net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.datasource mypool
hibernate.connection.provider_class net.sf.hibernate.connection.DatasourceConnectionProvider
|
其它参数就不必写了，因为已经在App Server配置连接池的时候指定好了。
如果你不是在App Server环境中使用Hibernate，例如远程客户端程序，但是你又想用App Server的数据库连接池，那么你还需要配置JNDI的参数，例如Hibernate连接远程Weblogic上的数据库连接池：
| java代码: |
|
hibernate.dialect net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.datasource mypool
hibernate.connection.provider_class net.sf.hibernate.connection.DatasourceConnectionProvider
hibernate.jndi.class weblogic.jndi.WLInitialContextFactory
hibernate.jndi.url t3://servername:7001/
|
最后，如果你需要在EJB或者JTA中使用Hibernate，需要取消下行的注释：
| java代码: |
|
hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory
|
杂项配置：
| java代码: |
|
hibernate.show_sql false
|
是否将Hibernate发送给数据库的sql显示出来，这是一个非常非常有用处的功能。当你在调试Hibernate的时候，让Hibernate打印sql语句，可以帮助你迅速解决问题。
| java代码: |
|
#hibernate.connection.isolation 4
|
指定数据库的隔离级别，往往不同的数据库有自己定义的隔离级别，未必是Hibernate的设置所能更改的，所以也不必去管它了。
| java代码: |
|
hibernate.jdbc.fetch_size 50
hibernate.jdbc.batch_size 25
|
这两个选项非常非常非常重要！！！将严重影响Hibernate的CRUD性能!
| java代码: |
|
C = create, R = read, U = update, D = delete
|
Fetch Size 是设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数。例如一次查询1万条记录，对于Oracle的JDBC驱动来说，是不会1次性把1万条取出来的，而只会取出Fetch Size条数，当纪录集遍历完了这些记录以后，再去数据库取Fetch Size条数据。因此大大节省了无谓的内存消耗。当然Fetch Size设的越大，读数据库的次数越少，速度越快；Fetch Size越小，读数据库的次数越多，速度越慢。这有点像平时我们写程序写硬盘文件一样，设立一个Buffer，每次写入Buffer，等Buffer满了以后，一次写入硬盘，道理相同。
Oracle数据库的JDBC驱动默认的Fetch Size=10，是一个非常保守的设定，根据我的测试，当Fetch Size=50的时候，性能会提升1倍之多，当Fetch Size=100，性能还能继续提升20%，Fetch Size继续增大，性能提升的就不显著了。因此我建议使用Oracle的一定要将Fetch Size设到50。
不过并不是所有的数据库都支持Fetch Size特性，例如MySQL就不支持。MySQL就像我上面说的那种最坏的情况，他总是一下就把1万条记录完全取出来，内存消耗会非常非常惊人！这个情况就没有什么好办法了 
Batch Size是设定对数据库进行批量删除，批量更新和批量插入的时候的批次大小，有点相当于设置Buffer缓冲区大小的意思。Batch Size越大，批量操作的向数据库发送sql的次数越少，速度就越快。我做的一个测试结果是当Batch Size=0的时候，使用Hibernate对Oracle数据库删除1万条记录需要25秒，Batch Size = 50的时候，删除仅仅需要5秒！！！ 可见有多么大的性能提升！很多人做Hibernate和JDBC的插入性能测试会奇怪的发现Hibernate速度至少是JDBC的两倍，就是因为Hibernate使用了Batch Insert，而他们写的JDBC没有使用Batch的缘故。以我的经验来看，Oracle数据库 Batch Size = 30 的时候比较合适，50也不错，性能会继续提升，50以上，性能提升的非常微弱，反而消耗内存更加多，就没有必要了。
| java代码: |
|
#hibernate.jdbc.use_scrollable_resultset true
|
设定是否可以使用JDBC2.0规范的可滚动结果集，这对Hibernate的分页显示有一定的作用，默认就好了。
| java代码: |
|
#hibernate.cglib.use_reflection_optimizer false
|
默认打开，启用cglib反射优化。cglib是用来在Hibernate中动态生成PO字节码的，打开优化可以加快字节码构造的速度。
不过，当你在调试程序过程中，特别是和proxy，lazy loading相关的应用中，代码出错，但是出错提示信息有语焉不详，那么你可以把cglib优化关掉，这样Hibernate会输出比较详细的调试信息，帮助你debug。
Hibernate的灵活性也是一把双刃剑，用好了就特别舒服，用不好，就特别头疼。把我原来在jdon一个帖子转过来，谈到了这个问题：
一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。
二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。
三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：
传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB
就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。
2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。
3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。
4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。
四、EB和Hibernate学习难度在哪里？
EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。
当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。
Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？
这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。