聊聊 OOP 和 DBMS 的鸿沟，聊聊填补鸿沟的 ORM

       本文不作深入讨论，就是聊聊 OOP、DBMS 和 ORM，聊聊，就是聊聊。聊聊有个好处——听个耳熟！

---

       OOP 的一个重要的信仰即是“面向对像”，也即对像作为唯一的“一等公民”。函数在 OOP 中被称为方法，并视其为对像的行为属性而附属于对像，而对于 OOP 来说，方法的唯一作用就是操作 OOP 的状态属性，也就是说，在 OOP 中，对像实施行为的最终效果就是自身状态的变更，也即所维护的数据的变更。

       既然 OOP 是通过一系列行为完成对状态属性，也即内部封装的数据的操作方式，那么可以提及数据库操作。数据库操作的最终效果也是所维护的数据的变更。

       二者的主要区别在于，一、从数据活动的主要场景看，OOP 中，内存是对像数据的主要活动空间，而数据库只是对像数据休眠（Hibernate）的地方，而数据库操作则不存在什么数据的活动，数据生死都只在于数据库表中；二、从结构层次上看，OOP 的对像具备层次和关系，对像的数据也因为对像的层次关系而存在着层次关系，而数据库内的数据没有层次，平铺在数据表里。在反映数据层次关系上，关系数据库有一种手段是拆分表，然后通过外键表达一对多的关系，但它与 OOP 的类层次结构相比有明显的区别和不匹配，如：

1、 当在设计中，乙和丙都派生于甲时，乙和丙都具备共性的字段，这使得乙和丙在数据表的存在方式显得不适应。若乙和丙存在于两个表中，则天然打破了乙和丙的内在联系。若乙和丙存在于同一表中，则造成了字段的浪费，因为在乙对像所在的行，无法填充丙对像的字段，同理于丙。

2、 一对多的关系中，比如一个班有若干学生，班表和学生表是分离的，并通过外键相关联。但在语义上，OOP 与数据库外键有着本质不同。在 OOP 中，对像班要表达的语义是：我是个班，我包含很多学生；而在关系数据库中，外键是建在学生表里的（比如学生表内的班级 ID），语义是：我是个学生，我属于某个班。这虽然看似是表达的是同一关系，却是两种完全不同的概念。最重要的是，同一关系，在不同的系统中，却是由不同的主体去表述的，这便对二者的沟通造成障碍。

       对于 OOP 来说，有一点非常关键，需要强调：对像在内存里生存、活动，数据库只是对像休眠（Hibernate）的地方。这里面的数据库并非专指关系数据库，也可以是文件。

       那么如何将对像保存到数据库，有一个手段是使用 ORM，即 Object/Relation Mapping。可以说，ORM 是由 OOP 的需要而产生的。ORM 解决了将内存对像保存到数据库，或从数据库中查找读取对像到内存的问题。Hibernate 就是一种 ORM，LINQ 也是。

        上面谈到了 OOP 与关系型数据库之间的鸿沟，ORM 的存在的意义就是填补之。比如说，ORM 封装了 SQL，将对像数据与 SQL 解耦合，不用去管该怎么样用 SQL 完成对像与数据库之间沟通的操作（无论是根据所查字段儿的需要临时拼接 SQL 还是事先准备好所有可能字段儿组合的 SQL），使得在 ORM 之外可以完全将思维站在 OOP 上，与 DBMS 沟通的工作全部扔给 ORM 去完成，也根本不用分一点精力去在乎 ORM 是如何完成的，这大大有助于 OOP 开发。