对象关系映射(Object Relational Mapping,简称ORM)是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技巧。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动长久化到关系数据库中。本质上就是将数据从一种模式转换到另外一种模式。 这也同时暗示者额外的执行开销;可是,如果ORM作为一种中间件实现,则会有很多机会做优化,而这些在手写的长久层并不存在。 更主要的是用于控制转换的元数据需要提供和管理;但是同样,这些花费要比维护手写的方案要少;而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。
对象-关系映射(Object/Relation Mapping,简称ORM),是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业求实体的两种表现形式,业求实体在内存中表现为对象,在数据库中表现为关系数据。内存中的对象之间存在关联和承继关系,而在数据库中,关系数据无法直接表达多对多关联和承继关系。因此,对象-关系映射(ORM)系统一般以中间件的形式存在,主要实现程序对象到关系数据库数据的映射。
面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的,而关系数据库则是从数学理论发展而来的,两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。
让我们从O/R开始。字母O根源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面,都存在对象和关系数据库。在业务逻辑层和用户界面层中,我们是面向对象的。当对象信息发生变化的时候,我们需要把对象的信息保存在关系数据库中。
当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码,用来从数据库保存,删除,读取对象信息,等等。你在DAL中写了很多的方法来读取对象数据,改变状态对象等等任务。而这些代码写起来总是重复的。
如果打开你最近的程序,看看DAL代码,你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例,你传入一个对象,为SqlCommand对象添加SqlParameter,把所有属性和对象对应,安设SqlCommand的CommandText属性为存储过程,然后运行SqlCommand。对于每个对象都要重复的写这些代码。
除此之外,还有更好的办法吗?有,引入一个O/R Mapping。实质上,一个O/R Mapping会为你生成DAL。与其自己写DAL代码,不如用O/R Mapping。你用O/R Mapping保存,删除,读取对象,O/R Mapping负责生成SQL,你只需要关心对象就好。
对象关系映射成功运用在不同的面向对象长久层产品中,如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。
一般的ORM包括以下四部分:
一个对长久类对象举行CRUD操作的API;
一个语言或API用来规定与类和类属性相关的查询;
一个规定mapping metadata的工具;
一种技术可以让ORM的实现同事务对象一起举行dirty checking, lazy association fetching以及其他的优化操作。
二、目前流行的 ORM 产品
目前众多厂商和开源社区都提供了持久层框架的实现,常见的有:
Apache OJB (http://db.apache.org/ojb/)
Cayenne (http://objectstyle.org/cayenne/)
Jaxor (http://jaxor.sourceforge.net)
Hibernate (http://om)
jRelationalFramework (http://ijf.sourceforge.net)
mirage (http://itor.cq2.org/en/oss/mirage/toon)
SMYLE (http://om/phrase/200604040935115.html" target="_new">oracle.com/products/ias/toplink/index.html)
其中 TopLink 是 Oracle 的商业产品,其他均为开源项目。
其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位,甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的好多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准,这也是开源项目影响工业领域标准的有力见证。
三、对象-关系映射模式
从《公共仓库元模型:开发指南》一书第8章CWM元仓库中摘录出来的内容,实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射,是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。
基本情况:公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准,采用UML表示的对象层次结构,在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流),所以该书的作者倾向于使用成熟的关系型数据库来保存-这也是存储本体时所遇到的问题。
采用方法:将UML模型中的各种元素通过转换,保存为数据库模式。由于CWM是一种元模型,因此模型的实例也是一种模型,将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术进步开发和执行效率。
1、数据类型映射模式
1.1简单数据类型模式:开办UML和关系型数据库中简单数据类型的映射表以指导映射。
1.2枚举数据类型模式:每种枚举类型对应一个表,只有一个列(_EnumLiteral)表示枚举值。
1.3基于类的数据类型模式:使用外键约束,将基础列与基于类的类型实例相关联。
2、类映射模型
每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射,而引用属性将在关联映射模式中提到。
2.1单值属性模式:是cardinality的上界为1的属性,映射到类所对应的表的列上。若其下界也为1(必须有的属性),列属性为NOT NULL。
2.2多值属性模式:每个多值属性映射成一个独立的表,使用外键连接到类所对应的表上。
2.3继承模式:每加入一个类的实例时,根据其继承关系自顶向下生成每个类的对象,这些对象拥有相同的ID(根对象对应登记的主键)。删除对象实例时,自底向上删除数据。遇到从中间删的情况怎么办?多重继承怎么处理?(金龙飞)
3、关联映射模式
3.1一对一关联模式:在关联两端各加一列。
3.2一对多关联模式:和3.1一样。如果多这端是有序的,还需加入一列表示序号。
3.3多对多关联模式:将关联单独作一个表。
3.4组合关联模式:注意级联式删除。
3.5反演关联模式:关联两端指向相关的类型,和普通关联一样。
3.6成对关联模式:关联登记两个类间的关系,用交集类表示关联,表示成一个单独的表,每个关联对应一个表,用外键表示它们间的关系。
3.7关联上的OCL需要分析成对应的存储过程代码。
3.8保证关联的cardinality也需要分析成对应的存储过程代码。
4、引用映射模式
在UML中不存在的MOF特征,指属性是声明为引用类型的实例。用存储过程实现。
四、ORM目标
1 、ORM 框架是为了解决什么问题而出现的呢?
面向对象建模和编程经过这么多年的发展已经相当成熟,其优势在于能够适应软件开发过程中的不断变化的需求。在面向对象编程的时候很显然我们建立的对象是放在计算机内存之中,如果关闭计算机那么我们的对象就不存在了,对象的永久性(也就是长久保存对象)是我们一直的期望。在O/R Mapping出现前我们设计程序不得不花费大量的精力和时间构建我们的Data Access Layer (DAL数据存取层),如果项目规模比较大的时候可想而知这个DAL层的复杂程度,涉及到异构数据库那就更加复杂。
2、ORM 框架 的出现是为了解决两个问题:
1). 数据库无关性:平滑迁移数据库和异构数据库;
2.) 实体对象的持久性:关系数据库的数据与对象的对应关系。
从这里就可以初步看出,架构至少有两个层次:
1. 数据库存取层Database Access Layer作为核心层,实现数据库无关性;
2. 实体对象映射层 ObjectMapping Layer 作为应用层实现数据到实体对象的映射,该层依赖于核心层。
1.数据库存取核心层是独立通用处于最底层的实现,可以直接拿出来使用的,必须保持高效和安全,主要的功能如下:
* 规范数据库操作,构造 Database 工厂模式(可拓展性),形成数据库操作类 【微软的 Data Access Application Block 】
* 规范 SQL 语句,解决不同的数据库之间的 SQL 语句的差异【最简单的方式方式就是在程序中以SQL语句Id的形式调用SQL语句,将SQL语句集中于一个文件。iBatis 的 DataMapper 采用类似机制,不过它采用的是XML格式,格式的冗余数据降低了加载的效率,在保存加载机制上不够灵活,至少该让用户选择保存为不同的格式;iBatis DataMapper 另一个问题就是将 ObjectMapping 也包含其中,层次不分明,降低可复用性,】。
2.实体对象映射层考虑的问题就多了:
* 简单实体对象属性的映射
* Collection对象属性的映射,如实体对象购物车的物品清单就是一个Collection对象属性,收录了该购物车中的所有的物品。
* 实体对象 MetaData 的考虑,
* 业务规则,约束的考虑等等。。。
这里实体对象映射层是效率最低的一个层次,原因在于映射操作:将实体对象变为数据库数据,数据库数据变为实体对象,而正是这个映射操作使得运行速度大大降低,内存占用大大的增加。如果将所有的实体数据不分青红皂白全部对象化,那么即使是采用Cache(是以牺牲内存为代价的)和分页机制(一次不要取个万把千条数据的,客户也看不过来,一次百来条数据就差不多了,这样就减少了内存的占用和映射操作的时间),但是,当系统面临逐渐增加的并发访问数量面前,系统的性能恶化相当厉害。企业级应用,也许是特指那些愿意花高价购买IBM RS/6000之流的机器的冤大头们吧。但是对于我们这些搞技术的,则是该将注意力集中在如何充分挖掘机器的每一分潜力上才是,相信对于每一个量入为出的企业来说,它应该是欣赏的。这个目前也没有想到什么好的办法,对于减少内存开销,有个建议就是在设计时候,尽可能的延迟加载时间(如实体对象购物车的物品清单,实际数据的加载只有当访问该属性的时候才加载,而对于大的备注,Blob类型的属性也可以采取类似的机制)。实际上,大多数用户的操作都是在浏览,因此对于浏览数据的形式,可以绕过ObjectMapping层,通过数据库存取层返回dataset直接操作,这样也能进一步提高速度和降低内存的消耗。
冠亿科技,尽心尽力
五、代码参考
1: static List<Object> getObjects(String sql, Class clazz)
2: throws SQLException, Exception, IllegalAccessException,
3: InvocationTargetException {
4: Connection conn = null;
5: PreparedStatement ps = null;
6: ResultSet rs = null;
7: try {
8: conn = JdbcUtils.getConnection();
9: ps = conn.prepareStatement(sql);
10: rs = ps.executeQuery();
11: String[] colNames = getColNames(rs);
12:
13: List<Object> objects = new ArrayList<Object>();
14: Method[] ms = clazz.getMethods();
15: while (rs.next()) {
16: Object object = clazz.newInstance();
17: for (int i = 0; i < colNames.length; i++) {
18: String colName = colNames[i];
19: String methodName = "set" + colName;
20: // Object value = rs.getObject(colName);
21: // try {
22: // Method m = clazz
23: // .getMethod(methodName, value.getClass());
24: // if (m != null)
25: // m.invoke(object, value);
26: // } catch (NoSuchMethodException e) {
27: // e.printStackTrace();
28: // //
29: // }
30: for (Method m : ms) {
31: if (methodName.equals(m.getName())) {
32: m.invoke(object, rs.getObject(colName));
33: break;
34: }
35: }
36: objects.add(object);
37: }
38: }
39: return objects;
40: } finally {
41: JdbcUtils.free(rs, ps, conn);
42: }
43: }
44:
45: private static String[] getColNames(ResultSet rs) throws SQLException {
46: ResultSetMetaData rsmd = rs.getMetaData();
47: int count = rsmd.getColumnCount();
48: String[] colNames = new String[count];
49: for (int i = 1; i <= count; i++) {
50: colNames[i - 1] = rsmd.getColumnLabel(i);
51: }
52: return colNames;
53: }