这是一个创建于 193 天前的主题，其中的信息可能已经有所发展或是发生改变。
Transient （瞬时状态）
Persistent （持久化状态）
Detached （游离状态）
Removed （删除状态）
八股概念记不住，
为什么要设计这几种状态？怎么理解？
Persistent （持久化状态）
Detached （游离状态）
Removed （删除状态）
八股概念记不住，
为什么要设计这几种状态？怎么理解？
9 条回复 • 2024-06-20 10:55:49 +08:00
 |
1
luzemin 193 天前
.NET 的 ORM EF 也是多种状态
Detached Added Unchanged Modified Deleted https://learn.microsoft.com/en-us/ef/core/change-tracking/#entity-states |
 |
2
nbndco 193 天前 via iPhone
最简单的方式就是问自己，哪个状态能够删掉？毕竟这些状态的设计都是非常自然的，属于哪种谁设计都是这几个
|
 |
3
bxb100 193 天前
最大的作用就是用于一级缓存, 级联操作吧
|
 |
4
kneo 193 天前 via Android
无非是为了兼顾性能和可靠性。自己照着文档挨个过一遍吧。
|
 |
6
abcbuzhiming 193 天前  4
@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 的这个过程搞的漂亮点 |
 |
7
zhazi 192 天前
将数据库事务操作抽象成对象状态，
用户在使用 ORM 的时候只考虑对象本身即可。 目的是降低使用者的学习负担，不需要考虑数据库的操作了 |
 |
8
chuck1in 190 天前
@abcbuzhiming 但是现在 node 和 golang 那一套技术栈最火的还是 orm 框架的感觉，不知道这是什么原因呢，按理来说这两个语言是没有历史包袱的。
|
|
9
abcbuzhiming 190 天前
@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 。但是这个思路现在看是不成功的 |
Select Language