hibernate 为什么给 entity 设计四种状态？

[laofan666]

Transient （瞬时状态）
Persistent （持久化状态）
Detached （游离状态）
Removed （删除状态）

八股概念记不住，
为什么要设计这几种状态？怎么理解？

[luzemin]

.NET 的 ORM EF 也是多种状态
Detached
Added
Unchanged
Modified
Deleted

https://learn.microsoft.com/en-us/ef/core/change-tracking/#entity-states

[nbndco]

最简单的方式就是问自己，哪个状态能够删掉？毕竟这些状态的设计都是非常自然的，属于哪种谁设计都是这几个

[bxb100]

最大的作用就是用于一级缓存, 级联操作吧

[kneo]

无非是为了兼顾性能和可靠性。自己照着文档挨个过一遍吧。

[chuck1in]

@luzemin 除了 java 和 .net 以外其他语言的 orm 是不是也有这么多状态呢。

[abcbuzhiming]

@chuck1in ORM 是不限语言的一种思路，核心思想是想用面向对象来取代关系运算（虽然它名字叫“对象关系映射”）。所以你用面向对象的思路去思考它，暂时把关系运算的思路放一边比较好。

另外 ORM 的思路从现在看是失败的，因为对象关系并不能真的替换掉关系运算，所以 ORM 这个东西和 SQL 之间存在阻尼，这就是用起来各种不舒服的核心所在。现存的 ORM 也就剩下 java 的 hibernate 和.net EF 了，其它的认真来说都不能算 ORM ，是基于 active record 思路（创始者是 ruby on rail ）的 sql 强化工具。对关系数据库的访问方式最终还是回归到 sql 本身了。

当然，最近国内又有一些作者开始折腾了，但是他们的思路也不是 ORM 的思路，它们的思路是希望通过链式 api 调用，使其能映射几乎绝大部分 SQL 的想法，老实说我不是很看好，因为我觉得复杂 sql 最合适的思路还是直接写 sql 。

总之，ORM 的核心是 O ，而不是 R ，但是这个思路没走通，之后的绝大部分关系数据访问库，都倾向于 R ，分歧不过是怎么把用 R 的这个过程搞的漂亮点

[zhazi]

将数据库事务操作抽象成对象状态，
用户在使用 ORM 的时候只考虑对象本身即可。
目的是降低使用者的学习负担，不需要考虑数据库的操作了

[chuck1in]

@abcbuzhiming 但是现在 node 和 golang 那一套技术栈最火的还是 orm 框架的感觉，不知道这是什么原因呢，按理来说这两个语言是没有历史包袱的。

[abcbuzhiming]

@chuck1in 这两家有 orm 框架？没有吧，不如你举一个，我印象里这两家出的都是 sql tools 。不是说自己是 ORM 就是 ORM 的，ORM 的核心是 O ，奔着用 Object 取代 SQL 去的，所以无论 hibernate 还是 EF ，这两家都在 Object 上下了很大的功夫，所以 object 有很多状态，并用复杂的嵌套结构来映射 join 查询。而且他们有一个特征就是，当你没办法非得用 sql 的时候，非常麻烦，因为当年他们摆明了希望取代 sql 。
后来的 sql framework 基本都没有这么干，虽然他们保留了 object 和允许嵌套，但没有把 object 设计的非常复杂。同时都提供了很方便的直接写原生 sql 的能力。也就是说，后来的库基本都倒向了 R 。倒向 R 和 ORM 的想法就背离了，ORM 的核心是 O 。但是这个思路现在看是不成功的