Hibernate领域模型

领域模型

Hibernate的领域模型，其实就是所谓的持久化类。在一个使用了Hibernate的项目中，领域模型相当于一个中心组织，它在开发新的程序功能的时候，会被大量地使用，下面讲讲领域模型设计需要遵从的一些规则。

1.将业务关注点和横切关注点（事务、日志、安全）进行分离，你的领域模型中不应该包含有与横切关注点相关的代码。

2.不要与特定的API进行耦合，因为要保证你的领域模型具有足够高的重用性和灵活性，那么就不要跟一些特定的API耦合。

现在有一种比较流行的领域模型开发方式——贫血POJO类，这些POJO类只包含了基本的业务数据和对应的存取方法，这样的POJO类就非常符合上述的两种规则。

领域模型建模

领域模型的建模，其实跟E-R图是非常相近的，也是从业务规则中抽取出跟业务相关的实体，理清实体跟实体之间的联系。举一个在线拍卖系统来说，用户拿商品进行拍卖，然后其他用户可以出价，从这里可以抽取出三个实体：用户User、商品Item和出价Bid

透明和自动持久化

领域模型的持久化应该是怎么样的呢？透明指的是，你可以在不知道底层是怎么实现持久化的情况下，底层帮助你进行领域模型的持久化。所谓的自动持久化，就是不需要人为地编写一些SQL语句和调用JDBC的API来完成持久化工作。Hibernate在进行领域模型持久化时就是透明的和自动化的。它根据ORM的映射规则，来自动生成SQL语句并执行。

领域模型是否需要序列化（Serializable）

Hibernate并不要求领域模型实现Serializable接口，但是根据项目的实际需求，来决定是否实现序列化。如果你的领域模型需要在Session(这里是指HttpSession)中传播或者RMI中传播，那么领域模型序列化是必需的；如果不需要，你可以选择不去序列化领域模型。

领域模型中的关联

关联有一对一、一对多、多对多关联，在面向对象的Java中，这三种关联都可以很好地表示，一对一关联就是单一类的实体，而一对多多对多关联，包含了多的一方要使用集合，一般情况下，都会选择使用Set集合。

关联在面向对象的Java中，还存在方向，即所谓的单向和双向。选择单向还是双向，根据我们的数据导航计划来选用，比如说一个User有一个UserDetail（说明用户详细信息的实体类），正常情况下，可以由User导航到UserDetail（通过getter方法），一般不需要从UserDetail导航到User，所以此时选择单向的数据导航计划就可以了。

领域模型中是否应该包含业务逻辑方法

这是让人比较纠结的一个问题，在分层的应用程序架构中，业务逻辑方法可以放在业务层的业务服务对象，由业务对象来进行逻辑实现。你也可以放在WEN层中，比如说Struts2来进行逻辑实现。上述的选择让你可以单单写一个只包含数据的贫血POJO类，所以，不一定要把业务逻辑方法写到POJO类中。但是将业务逻辑方法写到POJO类，可以减少其他层在业务逻辑实现时锁编写的代码。而且在《Hibernate in action》一书中，作者（Hibernate的实现者）是比较倡议在POJO中写上业务逻辑方法的。