hibernate总结

Hibernate总结

Hibernate是一种OOP的持久化实现。

1， OO和领域对象
什么是OO？
OO就是面向对象，就是自然而然的模拟对象和对象交互的编程实现。按照面向对象的要求一个好的OO要实现高内聚、低耦合。然而内聚和耦合本身就是一个彼此矛盾的概念——因此在OO的不同场合，我们要把握好不同的度，不要用一致的概念去要求OO的程度（比如在层次的划分上，在对象业务逻辑的划分上。。。。。。要求是不一样的。我们的目标是：最简洁的代码、最清晰的结构。）

话说回来，我们谈领域对象：
什么是领域对象？
领域对象是对业务知识的抽象，可以表现为UML图，可以表现为软件代码。按照我们上一段对“OO”的概念定义，我们要求这个对象要自然而然的模拟业务对象本身，以及业务对象的功能，同时还要符合一定程度的耦合内聚的要求。领域模型还有这样一层意义：领域模型是开发人员参与领域模型设计的开发方法（在EE的领域设计这本书里，模型分为：领域专家和分析人员的领域模型，以及开发人员的软件模型。前后两种模型容易不匹配。因此在软件开发阶段的领域模型，必须是开发过程和模型建模等多种概念的综合）

举例：银行ATM机
ATM.机器内余额
存款结果 ATM.存款操作（钞票） throw 各种异常
通讯消息 ATM.通讯（消息） throw 各种异常
……
一个对象是“数据和操作的封装”，所以我们一般不会对钞票进行建模，不会使用“钞票.操作”这种对象——这是（在业务建模上）没有意义的——但是就这个概念，引起过很多的争论，典型的就是贫血和充血模型。

我认为：贫血模型是不OO的，但是并不是说贫血模型不是最佳实践——事实上，贫血模型是java技术现状的最佳实践。在这种实践中，“业务层”和贫血deomain层对应了完整的领域模型操作和数据。好处是更纯粹。因为在现有的技术条件惯性下（不考虑hiberante），一个对象和另外一个对象发生关系，必然要涉及到持久化逻辑——这导致了对象职责分散。妥协的方案是既然不能OO，就不如干脆贫血。——所以我们知道OO并不是开发软件的最核心指导原则。

对于充血模型：我们首先要区分几种逻辑
1， 持久化逻辑
2， 模型内逻辑
3， 模型关联对象逻辑
4， 多个模型内不关联对象的逻辑
对于123，按照OO的原则，我们要求内聚。对于4，需要一个服务类，服务类专注多个模型间的消息以及处理流程。
BTW：很多人对持久化逻辑比如save update等保持在模型内可能争议不大，但是对于查找类的逻辑放到模型内，有疑问。认为这有点怪味道——其实我认为放到外边或者里面都行，我放到里面的是因为看起来更内聚（这个业务仅仅和这个模型相关，而且和其他的save等保持在同一个地方）

从一个更宏观的角度看充血模型和贫血模型都有domain和服务类，似乎没有什么不同，但是从一个更宽的角度看：充血模型更接近业务模型，更接近问题本身。充血模型完整的和业务设计等结合在一起。

理想中有一种想法：持久化作为一种标注性的服务被附加到业务模型上，而查找可以作为一种特定的技术和语言被此服务提供——以提供更透明、更简单的持久化解决方案。但是微观的看，我们必须定义对象和数据库的对应关系，以及持久化策略。

2， OO、对象和关系数据库持久化问题
接上一章的话题，我们谈OO、对象和关系数据库的持久化。
一个对象，包含了几个部分
1， 数据
这个是OO和关系数据库要关注的核心问题，即数据的持久化和关联数据的持久化
2， 领域逻辑『和持久化逻辑（如果不是写到服务类中的话）
持久化逻辑，领域逻辑的持久化，也可以考虑触发器、SP。并不一定非要编程实现（这应该是优先但不唯一的选择）
A映射策略
数据部分可能对应了数据库中的某张表，或者某几张表，这个时候我们要制定这个对象和表的映射策略：1对1、1对m、m对1等等。这是比较容易的部分。

而对象间的关系，比如组合和继承、也可能是映射策略的一个很重要的考量——尤其这涉及到sql和业务实现的时候。这个是关系数据库比较郁闷的地方。

B级联策略
OO的对象是级联，这种级联关系，要透明的反应到持久化数据库（的操作上）。

至于性能问题等等，不是ORM关注的关键问题——这是工程问题。对于这个工程问题，是通过上面几种策略以及缓存等的组合使用来解决的。

3， Hibernate对OO持久化要求的实现

。。。。。这部分我略了。因为我看过太多关于这一部分的文章。文章教授了如何写配置文件，如何一对一，如何级联。。。。。但是没有告诉大家：为什么要这么做，这么做的目的。
   这篇文章的额目的是将OO和HIBERNATE等作为一个体系串起来，形成一个bootswap，需要的时候，按此索引查找其他hibernate参考书。