你使用过对象关系映射吗?你对它留有什么样的印象呢?

如比如比 发布于 2015/06/14 08:42
阅读 1K+
收藏 2
你使用过对象关系映射吗?你对它留有什么样的印象呢?


比如:
优点:
1、大多数情况下不需要手写SQL语句,调用函数来完成对数据库CURD操作。
2、因为对数据库的连接以及操作进行了抽象,可以不需要考虑使用的是什么数据库(Mysql, oracle,etc)甚至于版本。


缺点:
1、对复杂的SQL还要手写。
2、在某些时候牺牲了性能。


别再憋着了,赶紧来一吐为快吧。
表完,你会有不一样的感觉的,不信,你试试。


------------------
对象关系映射(Object Relational Mapping,ORMapping,O/R mapping,ORM,O/RM)
用来实现面向对象编程语言里的对象和关系数据库的数据之间的转换。对象关系映射成功运用在不同的面向对象持久层产品中,如:Torque,OJB,Hibernate,TopLink,Castor JDO,TJDO,Active Record,NHibernate,ADO.NET Entity Framework 等
------------------


加载中
1
l
loyal的小号

所以,从来不用orm,要是用了orm也不用pojo。

只用map。也就是类似Active Record的方式~

包括前台后台数据交互都是map、json。。。工程里压根就没有pojo的存在。

nightmare123
nightmare123
回复 @whaon : 恩恩,是啊,不然java里面的javabean用来干嘛的,人家这么多年的技术也没那个说不用pojo的!
whaon
whaon
回复 @nightmare123 : 嗯,我个人觉得,可以不用那些orm框架,但是pojo还是需要的
nightmare123
nightmare123
回复 @nightmare123 : map只适合用简单的数据类型,假如都是那种复杂对象嵌套那种就很有局限性!
nightmare123
nightmare123
回复 @whaon : map其实很恶心的,更加不利于扩展和维护!
whaon
whaon
map比pojo好?
下一页
1
GITTODO
GITTODO
这个东西最早就是为了快速开发用的,如果你想快速开发,用它就行了。如果公司项人员多,分工细,有时间折腾,不用也一样
如比如比
如比如比
是这的样,在模式相似的数据库操作时,利用一些模版组件,能在很短的时间内组建起一个能操作的系统。
1
iehyou
iehyou

引用来自“loyal的小号”的评论

所以,从来不用orm,要是用了orm也不用pojo。

只用map。也就是类似Active Record的方式~

包括前台后台数据交互都是map、json。。。工程里压根就没有pojo的存在。

jfinal之类开发的确是快。。。。 在没有沉淀的开发框架的基础上, 没有工具生成bean,service等代码的话,手写累死了 我现在就是这个感觉。
如比如比
如比如比
所以,能结合velicity,filemaker等模版处理来迅速生成代码的话将能腾出更多的宝贵的时间来解决别的问题。从这个角度来看,如果orm把被认为是缺点的了改改,将会有更大的空间了。?
1
gys201
gys201

ORM (Object Relational Mapping) 是对象关系映射,就是把数据库的关系表映射到JAVA中的对象,在编程过程中,直接操作对象,就等于操作数据库关系表,便于程序员做快速开发,不需要考虑数据库的兼容性;实现原理 :是在数据操作SQL的基础对关系表进行了抽象封装以及对于各种数据库连接做了整合;

缺陷:由于做了一层封装,性能自然下降;操作JAVA来实现关系表操作,毕竟有限,对于复杂的逻辑操作还是需要SQL来实现;对于数据库级连操作,效率也是很低;

如比如比
如比如比
说的不错,看样子经历过了。
1
anycmd
anycmd
我们内部的事物
持久层和数据访问层都是非常简单的一层,复杂的持久层的问题已经被数据库厂商隔离在他们的领域内了,我们只把数据库当做了一种持久介质在用,除了数据库的标准的存取功能外的一切功能一个都没用,显然它肯定是可以跨数据库的,不只可以跨相对标准的关系数据库,而且可以跨任何非关系数据库。

无论是sql还是nosql,无论是object还是json和xml,他们本质都是一样的东西,都只是承载信息的形式,都能完整的描述信息,它们的形的不同只是为适配它们下面的运行时的不同(如果再往下一层的话不同的运行时也没有任何不同,它们都是集合和函数,都是空间和时间,都是时空)。sql、nosql、object、json、xml的本质都是Dictionary<string, object>(其中object又可以是Dictionary<string, object>类型),当涉及到两种表现形式的转换时我们只需把它们还原为Dictionary<string, object>一切真相都大白于天下了。

问题的关键是如何管理Dictionary<key, value>中的key,因为value有标准,而那个key不是,value都是int、string、char、varchar、boolen、datetime等在www下具有标准的事物,不管运行时是什么平台它们必定都会往www下协定的标准数据类型去适配,如果觉得int、string、char、boolean这个层次还不够的话,那就到0 1得了,到了0 1就再也没有任何的不同了。那个key是业务,那个value是机器。那个key是人类各行各业千百年来积累的知识和文明,那个value是物质,那就是物质和意识的关系。

如何处理那个key是实现我们的业务的关键
Dictionary<key, value>中的key需要通过一棵结构良好的树去管理(sql、nosql、object、json、xml等都是用来表现树的,它们之所以形状那么相似运动的那么相似都是因为它们描述的是同一个事物)。我们可以考虑把主要的精力放在如何管理这个key树上,这里有我们最多的价值。

一旦管理好了这个key树,任何业务系统的实现都会变得简单了。
管理好这套元数据的结果是JVM、CLR等事物仅仅充当cpu的作用,甚至电子的cpu都不需要。只要存在土比水稳定,水比土流动的快这种局部的不等性质我们就有办法把那个系统运行起来。

就是说最终我们应该有一棵树,根树下是一片森林,这片森林中承载的那些信息是中心、核心。展示层、业务逻辑层、持久层等都是那个中心的投影。并不是业务逻辑层中的object和持久层中的record去相互映射,它们不会直接映射,它们都是向那片森林映射。

梁山权限引擎抛弃ORM了

如比如比
如比如比
很有周易的象范。
1
梅开源
梅开源

人们以为自己thinking in java/php/python ……  

实际上多数时候都在thinking in SQL

后来有些人觉得这样亵渎了面向对象神教教义

于是把sql封装再封装,再发明一大堆名词成功实现了通过操作对象操作数据库!

类似地,还有发明一大堆名词成功实现了操作html!

梅开源
梅开源
回复 @茶壶 : 是啊,很悲催的在这个领域折腾好多年发现其实那么多东西还是翻不出SQL,html等五指山。换个环境又得用另外一套继续玩。
如比如比
如比如比
你这是看透了啦。
0
如比如比
如比如比
没有表态的是什么态度呀。
0
如比如比
如比如比
从我个人的角度还是很期望代码自动化的,不知道你们怎么看,其实这就是平常所说的ctrl+c,ctrl+v(这可能不适合搞framework开发的哦)。以上我之见。
0
如比如比
如比如比
@小小志 ,男子汉大丈夫,办事得光明磊落,平白无故不能总不能白踩一脚吧,又没招你,给个解释吧。
如比如比
如比如比
回复 @小小志 : 合着我这儿成实验田啦!好吧,有解释就结啦,好好珍惜这个成果吧。
小小志
小小志
就想试一下踩了还能不能改回去 结果改不回去了
0
如比如比
如比如比
@朱宏青 ,不能白踩,给个解释吧。
如比如比
如比如比
回复 @朱宏青 : 呵呵,系统有点不好用啊哈,后面的我也没有收到个信儿,那欧了。
朱宏青
朱宏青
已经取消掉了 没见只有-1了吗 我不小心点到了 实在抱歉 :)
如比如比
如比如比
@朱宏青 ,没招你,赶紧爷们点儿。
返回顶部
顶部