ORM原型概念

最新推荐文章于 2021-04-15 09:34:14 发布

cyGwendoline

最新推荐文章于 2021-04-15 09:34:14 发布

阅读量339

点赞数

分类专栏： php

php 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

转自：http://www.cnblogs.com/chenkai/archive/2011/01/06/1929040.html

ORM原型概念作者：chenkai

ORM[Object-Relation-Mapping]对象关系映射. 这个名词已经出来好几年了.已经不陌生. 以前在项目中针对相对复杂业务逻辑时一般采用领域模型驱动方式进行业务概述,分析和建模. 其中在设计阶段我第一次接触ORM这个概念. 针对实际项目中ORM 采用的是Nhibernate实现底层数据持久化. 当然现在ORM成熟的工具已经很多了. 本篇的目的结合以往实际编程经验.系统整理ORM原型概念.

<1>什么是ORM?

解释这个名词并不难.先了解一下ORM由来. 其实ORM的需求真正由来是在随着面向对象OO编程开发方法发展而产生的. 如今面向对象[Object]的OO编程已经成为企业级开发中主流开发方法. 而关系型数据库也成为企业级应用环境中永久存放数据的主流数据存储系统. 其实到这你应该明白. 同样的数据一个是在实际编程中一Object面向对象方式体现, 而另外一种就是把这种内存对象持久化存储到硬盘文件上.

由此可以说对象[Object]和关系数据是业务实体的两种不同表现形式.业务实体Object在内存中表现为对象，在数据库中表现为关系数据.

2011-01-06_153541

内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射.

这时有人会问为什么需要ORM?

先从项目中数据流存储形式这个角度说起. 简单拿MVC这种分层模式.来说. Model作为数据承载实体. 在用户界面层和业务逻辑层之间数据实现面向对象OO形式传递. 当我们需要通过Control层分发请求把数据持久化时我们会发现. 内存中的面向对象的OO如何持久化成关系型数据中存储一条实际数据记录呢？

面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的. 两者之间是不匹配的.而ORM作为项目中间件形式实现数据在不同场景下数据关系映射. 对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术.ORM就是这样而来的.

2011-01-06_161244

<2>ORM作用与优缺点?

ORM推出在某种程度上打破我们架构上设计.同时也带来一些没有使用ORM之前不曾出现问题. 但最值得肯定是编码效率获得一定提高.可以把更多精力和时间从底层数据访问层代码重复工作中解放出来.关注程序和业务本身. 这时ORM所带来程序员生产力提高

另外一个不得不说就是维护的成本. 以前我们用ADO.NeT搭建的庞大复杂数据访问层. 我想在MVC架构UI 和Control可以实现层与层之间的解耦.而数据访问层DAtaAccess Layer却时候关联业务逻辑中. 当发生轻微变动时就要修改底层数据访问层.这样维护频率和灵活度.大为令人诟病. 可想而知这样维护成本也是很庞大费时费力的事情.

ORM体现特点:

<1>提高开发效率.ORM框架自动实现Entity实体的属性与关系型数据库字段的映射.CRUD的工作则可以交给ORM来自动生成代码方式实现.打打提高我们开发效率. 这样一来也减少我们维护一个复杂缺乏灵活性数据访问层的成本.

<2>NOSQl数据操作.NOSQL 数据库最近几年才提出这个概念主要用在一些开源数据库上.类似Repid DB上而ORM中无需直接操作T_SQL语句，实现数据操作. 其实了解作为Hibernate的创始人，Gavin King在设计Hibernate是全然不知T_SQL如何使用. 这让很多人汗然一把.

<3>来说说目前ORM这种模式缺点.

相信很多用过Herberate或是.NEt版本的.NHerberate的应该了解. 我们在搭建好项目结构后. 做好XML数据库访问配置文件. 然后就可以轻松根据数据实体EntityModel实现数据的CRUD操作. NOSQL的操作让我们开发效率得到质的飞跃. 可是等项目中期进入测试我们DBA看到数据库连接SQL语句说了一句"F**k 链接这么长的SQL是有病吗？“ 为何这么说呢？

假设我们DBA遇到事这样场景. 类似我们现在做一个系统访问权限验证. 数据库设计表之间实现6张表关联. 在的大数据量情况下. CRM给我们生成一些低效访问SQL 照成我们性能一直上不去. 虽然自动生成代码但你看NHerberate并不是每次生成代码都是具有高性能满足你的需求. 于是你的DBA那天给你说 “哪个XX某某. 你把这段访问做一下SQL优化一下？” 回日:“那是NHerberate自动生成的和我有什么关系？” DBA:”于是很抓狂说了一句多连接情况T_SQL会照成多次访问死锁?必须得优化.” 回日:“那时Nherberate自动生成的我没法修改啊?” DBA“直接从极度抓狂中陷入崩溃……”

上面杜撰一下一段经历. 以前使用NHerberate使用过程说明CRM一个问题:

CRM的确定是在一定程度上牺牲了程序的执行性能和固定的思维模式.

A:首先从系统架构来说采用ORM这种方式作为底层数据访问层. 架构多数采用多层架构方式. 系统架构分层越多同时面向对象这种编程方式执行效率也随之降低. 类似一个普通支持多数据架构方式MyBatis ORM框架架构方式如下图：

22170746_ryew