再论 ORM

Object-Relationl Mapping，它的作用是在关系型数据库和对象之间作一个映射。

ORM 对象关系映射，这样说还是懵。 这里比较难理解的是 关系 —— 即Relationl ，虽然看起来是形容词，但是理解为名称应该更加合理。当然，也不要纠结这个。可以这样理解，对象：java Model，对应一个实体类，关系：关系型数据库，对应一个数据库表，映射：就是具体对应关系。ORM 其实是 更加自然的表述了我们对事务的描述，类似ER图（仅仅是概念层面）一样，对象数据库的PDM（仅仅是数据库层面） 文件一样。 但是ORM 更深了一步，它跨越了 数据库和 应用程序。 它 更多关注的是 映射。 使得我们可以 隐藏某些数据库的细节，从而 “更加直接的” 通过应用程序来操作数据库。虽然减轻了某些方面的工作，但是也对我们的提出了额外的要求， 就是我们需要来仔细维护这个 “映射”。

映射是必不可少的， 我们通常需要一个 xml 文件来描述这个映射。 当然， 现在JPA 也可以使用 注解了。常见的映射种类有：

3、关联映射模式
3.1一对一关联模式：在关联两端各加一列。
3.2一对多关联模式：和3.1一样。如果多这端是有序的，还需加入一列表示序号。
3.3多对多关联模式：将关联单独作一个表。
3.4组合关联模式：注意级联式删除。
3.5反演关联模式：关联两端指向相关的类型，和普通关联一样。
3.6成对关联模式：关联记录两个类间的关系，用交集类表示关联，表示成一个单独的表，每个关联对应一个表，用外键表示它们间的关系。
3.7关联上的OCL需要分析成对应的存储过程代码。
3.8保证关联的CARDINALITY也需要分析成对应的存储过程代码。

映射关系是很多种的，上面也仅仅是一部分而已。 更多的映射，需要特定场景才有用到。Hibernate 对我们的这种映射做了很多 封装工作。

在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。

优势

第一：隐藏了数据访问细节，“封闭”的通用数据库交互，ORM的核心。他使得我们的通用数据库交互变得简单易行，并且完全不用考虑该死的SQL语句。快速开发，由此而来。

第二：ORM使我们构造固化数据结构变得简单易行。在ORM年表的史前时代，我们需要将我们的对象模型转化为一条一条的SQL语句，通过直连或是DB helper在关系数据库构造我们的数据库体系。而现在，基本上所有的ORM框架都提供了通过对象模型构造关系数据库结构的功能。这，相当不错。

缺点

第一：无可避免的，自动化意味着映射和关联管理，代价是牺牲性能（早期，这是所有不喜欢ORM人的共同点）。现在的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。

第二：面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象,但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本.

第三：对于复杂查询，ORM仍然力不从心。虽然可以实现，但是不值的。视图可以解决大部分calculated column，case ，group，having,order by, exists，但是查询条件(a and b and not c and (d or d))。

世上没有驴是不吃草的(又想好又想巧,买个老驴不吃草)，任何优势的背后都隐藏着缺点，这是不可避免的。问题在于，我们是否能容忍缺点。

常用的ORM框架

（1）Hibernate  全自动，需要些hql语句

（2）iBATIS  半自动自己写sql语句,可操作性强,小巧

（3）EclipseLink  一个可扩展的支持JPA的ORM框架，供强大的缓存功能，缓存支持集群。

（4）Apache OJB等等

（5）JPA

显然， Hibernate  对ORM支持是最好的，mybatis 不是那么好。ORM 不是银弹，虽然我们不再需要直接面对sql 、jdbc，但是，我们又多了一个工作，我们需要管理映射。

对于Hibernate，我们需要编写hbm.xml文件。

对于iBATIS  、mybatis ，我们需要写 mapper 的 xml文件，xml里面需要映射 然后还要写 sql 文件。当然，现在的 tk-mybatis / mybatis-plus 好像不用写 sql 文件了。

对于JPA，好像就跟 mybatis-plus 一样的。 （我现在有点搞不清楚两者区别）

ORM（Object Relational Mapping）框架采用元数据来描述对象一关系映射细节，元数据一般采用XML格式，并且存放在专门的对象一映射文件中。

只要提供了持久化类与表的映射关系，ORM框架在运行时就能参照映射文件的信息，把对象持久化到数据库中。当前ORM框架主要有五种：Hibernate(Nhibernate)，iBATIS，mybatis，EclipseLink，JFinal。
ORM是通过使用描述对象和数据库之间映射的元数据,在我们想到描述的时候自然就想到了xml和特性(Attribute).目前的ORM框架中,Hibernate就是典型的使用xml文件作为描述实体对象的映射框架,而大名鼎鼎的Linq则是使用特性(Attribute)来描述的。

元数据
是描述其它数据的数据 （data about other data），或者说是用于提供某种资源的有关信息的结构数据（structured data）。元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。

ORM与DB Helper Library：

很多人可能都接触过这类的helper，每个公司都有自己的helper。许多Helper提供了很多的强大的功能，封闭交互底层，实体类支持，提供SQL翻译功能。ORM比之这些Helper只是多提供了一层，他尝试封闭的自动化的（或是映射文件）来实现关联。以前，这都是我们手打的。（灵活替换数据库也算ORM优点，）

问题就在与有些人发现封闭的自动化关联满足他们需要了，所以ORM对他而言是成功的。而有些人发现封闭的自动化关联不适合他们的项目，所以ORM被诟病。

写到这里，我想不用多言了。该结束了。

我的观点是ORM试图取代helper，为此提供了更多的功能。他为了应付更加严格和复杂的企业需求而不断发展，在很多情况下，这些工具开始具有自身的复杂性，使得开发人员必须学习使用它们的详细规则，并修改组成应用程序的类以满足映射系统的需要，使用它们所面临的复杂性反而盖过了所能获得的好处。在我们的大部分项目中Helper依然是我们构建数据持久层的主力，ORM或许在有些项目(模块)中可以独揽一切，但是ORM（就目前而言）无法面对一切考验。

参考：

https://blog.csdn.net/zhanghongjie0302/article/details/47344417

https://baike.baidu.com/item/ORM

https://baike.baidu.com/item/ORM%E6%A1%86%E6%9E%B6/15541111

https://blog.csdn.net/sgear/article/details/7408251