Posted on 2006-06-07 11:04
冬冬 阅读(11684)
评论(35) 编辑 收藏 所属分类:
Architecture
我觉得ORM是什么：
回答初学者，ORM，Object-Relation Mapping，对象关系映射。主要用于实现业务逻辑和关系数据库中数据表的对应关系。让你摆脱访问数据库的细节。
我觉得ORM的好：
我觉得ORM最好的就是不用写SQL，不用写Connection，不用写Command，不用写DataAdapter了。当然还有就是换数据库的时候方便。
我觉得ORM的不好：
1，最重要的是：用不好的话就本末倒置。有了ORM，再加上代码生成，感觉只要有了数据库，整个项目就做得都差不多了。很容易让人有一种先作数据库，再用代码生成，再改改，再加上GUI就大功告成的感觉。这样，对吗？不用我说吧？
2，数据库驱动型开发。算是我造的一个词吧，有人用数据库驱动开发吗？
3，用起来麻烦，都要配XML，BusinessObject...代码生成好一点，但是总感觉生成的东西不放心，就算是自己写的（我也写过），也可能存在很多问题（是不是我的水平不够高？）。而且总是从业务逻辑中精心雕琢的代码切换成批发式的生成代码，感觉特别扭。
4，性能：都用反射了吧？昂贵的东西...
5，复杂的查询支持的不好：多表联合查询之类的。有些也可以实现，但是做起来比自己写Sql还麻烦。
我觉得ORM适合干什么：
1，做微型系统，特别是并发小的，或者没有并发的。
2，做原型系统。
欢迎批评指教，你的批评是我最好的教材。:)
Feedback
小驳一下
ORM并没有让你摆脱访问数据库的细节，而且你必须更了解数据库，不过这是在用好ORM的前提下，它带来的好处也是相当多的，起码不会手误写错sql语句，呵呵，我们的产品的下一个版本就准备用ORM，当然不是通用的ORM，而是自己定制的：)
ORM在系统需要做很多数据统计的时候很麻烦，简直要人命。
不过在一般的操作还是很方便的。
你必须有需求,然后分析设计,数据库才出来.数据库只是一个数据存储介质.
ORM也只是一种数据库处理的手段.
对于反射问题,实际上在头一次Mapping时用到后面的相关操作是不必要.这主要看你实现的方法.
对于复杂的查询支持的不好,主要看相关组件的实现.应该不算是ORM模式的问题.
如果是先设计数据库，然后再搞程序的话，orm只会带来麻烦，肯定不如sql方便。
使用orm，脑子里要这样想：我存储的是对象，而不是关系型数据。然后orm就把你的对象放到关系型数据库里去了。
配置麻烦的问题在 Castle ActiveRecord 里已经不存在了。可惜 ActiveRecord 的那个 generator 还是有一定 bug 的，总要手工再查一遍生成结果。
@川仔
不能因为不写错Sql就用ORM吧，这个好处应该不算。排除SQL最好的方法是测试。再说，有的ORM生成SQL...不敢恭维呀。
@jhtchina
把持久层写出来不违反OOP吧？
@henry
“你必须有需求,然后分析设计,数据库才出来.”
这个说的没错。然后呢？应该是领域模型或是事务吧？数据库是细节，一般推迟实现的。
@小陆
我觉得一般先不考虑持久化的问题吧？我在做项目的时候一般现实些业务逻辑，作业务逻辑的时候根本不考虑数据库，而是逻辑实现了，再考虑怎么持久化。
如果一开始就考虑持久化会不会很累呀？:)
“你必须有需求,然后分析设计,数据库才出来.” 数据库应该是数据结构模型.
为了方便模型反映到程序中,我常用的方法是先把模型反映到数据库中然后通过工具反映到程序中(既然模型已经规定，先反映到数据中还是程序中关系应该不大吧?)
如果一开始就考虑持久化会不会很累呀？
当你没这个需求的时候一开始做是没有必要的.减轻SQL语句编写的工作量,业务逻辑共享事务,不同对象操作数据共享连接等等.这系列的问题都是在处理数据库时要面对的,既然要面对这些问题那在设计时考虑进去是不是很应该?
如果你的业务逻辑是不关心这些,那考虑她是有点多余.
3，用起来麻烦，都要配XML，BusinessObject...代码生成好一点，但是总感觉生成的东西不放心，就算是自己写的（我也写过），也可能存在很多问题（是不是我的水平不够高？）。而且总是从业务逻辑中精心雕琢的代码切换成批发式的生成代码，感觉特别扭。
可以用一下MyGeneration的nibernate模版生成配置文件，很好用的。
4，性能：都用反射了吧？昂贵的东西...
DataGrid DataSet 还有不少asp.net的控件都是大量使用反射，难道我们就因为效率下降不用了吗？没有必要那么早考虑性能问题。
5，复杂的查询支持的不好：多表联合查询之类的。有些也可以实现，但是做起来比自己写Sql还麻烦。
对复杂的查询确实支持的不好，但是你可以通过写视图,然后将视图映射到类来解决这个问题。
我觉得ORM适合干什么：
1，做微型系统，特别是并发小的，或者没有并发的。
2，做原型系统。
和你的观点相反，我觉的orm适合用在大系统中，用来做原型系统和微型系统实在是浪费了
@kiler
谢谢你的批评指教，看了觉得很有意思。:)
咱们的观点好像正好反了呀！呵呵。
首先说，前台你怎么作页面的我不知道，反正我很少用控件，我喜欢自己写Html或者XHtml。这样美工兄弟也方便（一般是美工做Html）。而且我们做的项目一般都要求表现层和数据流分的比较彻底，一般不用直接整合。所以反射我真的不喜欢用，也不太常用，呵呵。
在大型系统中，数据库一般都是珍惜资源吧？好像ORM生成的Sql效率都不高，不如DA兄弟的存储过程来的舒服。还能支持优化。
再就是用起来，代码生成我已经说过一次了，或许是我自己写的代码生成器不好，但我真的不太喜欢代码生成那种批发的感觉，我喜欢精致的代码，而且我相信每一个对象的持久化都是有差别的。
还有一个问题：比如我要更新某网站的一篇文章，但只是制订改什么字段就更新那些字段，不指定的不更新（不指定的也可能已经变了），ORM怎么实现？
比如用户修改一篇文章的内容，但是不修改点击量的话，点击量应该不变，但这时候网站在运行，点击量应该是不更新，而不是用以读取的量覆盖。
@henry
有了模型为什么要先反射到数据库而不是直接反射到代码呢？而且一般做模型的时候不会做的非常细致。也不会先考虑好持久化的问题吧？
减轻SQL语句编写的工作量,业务逻辑共享事务,不同对象操作数据共享连接等等确实是设计时应该考虑的问题。但设计的是用也应该先考虑业务逻辑，不能让持久化来左右逻辑吧？
:)
有了模型为什么要先反射到数据库而不是直接反射到代码呢？而且一般做模型的时候不会做的非常细致。也不会先考虑好持久化的问题吧？
----
既然模型已经有了,争论那个先那个后有必要吗?我也没有说一定要优先考虑吧？在设计时总会想到是人手编写SQL语句还是用组件去代替这部分工作呢,如果用组件那数据结构模型又如何表达来适应它呢,相关人员能适应这各方式等等.这些东西难道不会去想(如果不想我觉得有点开玩笑，因为一但你用了数据库这些问题是必须面对的)；
但设计的是用也应该先考虑业务逻辑，不能让持久化来左右逻辑吧？
-----------------
举个例吧一个业务逻辑执行了很多数据操作方法.那你在设计时是不是应该想到这一点,让不同数据访问方法可以协同工作(包括共享数据连接和事务等).业务逻辑的内部处理就是由这些东西组成,没有这些东西这个业务逻辑还能工作？
这些问题在编写业务逻辑是要面对的！
考虑这些根本不影响业务逻辑的对外规则.因为UI调用业务逻辑是不关心它内部是如何处理的，既然考虑这些不影响业务逻辑的规则这又那来左右业务逻辑呢？
搂主似乎并没了解什么是ORM,ORM完全可以是MDA的一部分,并不是所谓的数据库驱动开发
还有ORM产品也不是全部都是用反射的.
gavin king (hibernate 的作者） 说过认为HIBERNATE在大型系统
和复杂关系中就会SHINING。我只赞成一半，写程序的角度可能是方便
很多，而且全都是OO的，是非常FLEXIBLE的。
可是ORM是真的很慢的，这种慢不是用C、C++或用JAVA，.net的比较，
而且是sql和存储过程运行规则的比较，SP如果在很多数据量时，比
正常的SQL是要高好多的。一个特定的语句优没优化过，是真的完全不
同，不然DBA也不会这么值钱了。
所以说ORM 做小系统比较麻烦，做大系统效率又不好。我想它的利用
价值在于数据库的中立性，如果是做产品的公司，要求很高的FLEXIBLITY
和扩大了自已的潜在市场。可如果是自已公司的企业级应用，我觉得
是比较没必要用ORM的。有几个公司真的是说换DATABASE就换了。
都是要用５年以上的。
@henry
有了设计、模型，我还是觉得应该先作业务逻辑、代码对设计有反作用力，数据库也有，但谁应该作用谁呢？显然业务逻辑作为系统的行为的描述，应该先与持久化。持久化应该依赖于业务逻辑。
代码，也是设计。
同样，业务逻辑应该通过抽象，决定持久性应该实现的东西，这也是为什么先要有业务逻辑，业务逻辑拥有接口，持久层只是实现而已。向你说的例子，共用的数据访问当然会有对应的接口。当然，怎么实现也是知道的研究的，这也正是DBA的价值所在。（BTW：这已经是构架的范围，而不是淡淡ORM了吧？:)）
@Na57
当然不全用反射了，这点我们可能有点误会。对象/关系映射，那我自己写的DataAccess中使用的某一个类来实现对应表的访问所不算呢？ORM说到底应该算作是一种实现数据存储的方法吧？而我讨论的更多的实现了的ORM框架，也可以说是狭义的ORM。
@gozh2002
观点一致，呵呵:)
@galford
大哥的这句话我觉得欠佳。ORM是一种方式，每个人的看法不同，在每个人的看法中都可以知道除了ORM之外的很多东西，比如开发方式等。在大家的讨论中更是能学到很多东西。以上大家激烈等讨论就是最好的证明。
写的很好。ORM真是个鸡肋。
对于企业应用来说，存在如下现实问题：
1.并不是所有的系统都是从头开发，往往是扩展，数据库不能根据你的需要随便定义。
2. 数据对于企业来说是最重要的，应用系统是为了处理业务数据而不是为了开发方便来设计数据库。
大家都说了那么多了，我也凑合一点，用IBatis.net的时候出了问题，调试起来可是真费事，除了排除法外似乎没有更直观的方法了。各位高人有好办法吗？
@维生素C.NET
建议你引用IBatis.net的源代码项目来调试吧，呵呵。
@冬冬
先业务逻辑是应该的,因为它描述了用户输入和输出规则就只是一个规则.这个规则在需求已经规定了.既然规则已经确定我们是不是应该把精力集中在实现上呢?
我想问有几那个项目在设计时是没有确定平台和数据库的?
虽然访问代码是为业务逻辑服务并不是依赖,因为一个方法可以给1-N个业务逻辑所使用!
数据访问代码在系统代码中的份量是多少,楼主应该比我清楚.如何达到一个好的重用性,如何不重复编写数据访问代码,如何提供编写SQL语句的效率等,在设计时楼主真的没考虑这些东西(不管你手写SQL语句或是用组件)?
如果业务逻辑不存在数据存储,那讨论是否考虑和设计数据存储方法也没意义了.
headchen说的对，我们的最终目的是为了处理业务数据而不是为了方便开发。
现在业界对于方便开发做的有点过了，忘了我们做系统的最终目的是为了处理业务数据
全是高手哈,有没有成都的高手?www.hand365.cn和我联系
1 说理论点：重在业务处理
2 具体到开发：ORM确实很方便快捷
3 任何事情都是：理论+实际的条件（时间，Money，==）
3，用起来麻烦，都要配XML，BusinessObject...代码生成好一点，但是总感觉生成的东西不放心，就算是自己写的（我也写过），也可能存在很多问题（是不是我的水平不够高？）。而且总是从业务逻辑中精心雕琢的代码切换成批发式的生成代码，感觉特别扭。
现在有很多代码生成工具都非常好用
4，性能：都用反射了吧？昂贵的东西...
其实根本不用考虑性能问题，你知道反射，那么你也应该知道有缓存这东西，把反射回来的信息放入缓存后（也就是说系统其实只需要反射一次），速度并不比你写数据集慢
5，复杂的查询支持的不好：多表联合查询之类的。有些也可以实现，但是做起来比自己写Sql还麻烦。
这个问题可以参考：
http://sukyboor.cnblogs.com
视图也不失为一个好办法
我觉得ORM适合干什么：
1，做微型系统，特别是并发小的，或者没有并发的。
好的orm框假可以对并发处理的更好（在o层对事物进行处理）
2，做原型系统。
这个我赞成，以业务--》模型-生成-》（数据库，代码）
生成原型系统特别方便
ORM的缺点是会牺牲程序的执行效率和会固定思维模式。
从系统结构上来看,采用ORM的系统一般都是多层系统，系统的层次多了，效率就会降低。ORM是一种完全的面向对象的做法，而面向对象的做法也会对性能产生一定的影响。
在我们开发系统时，一般都有性能问题。性能问题主要产生在算法不正确和与数据库不正确的使用上。ORM所生成的代码一般不太可能写出很高效的算法，在数据库应用上更有可能会被误用，主要体现在对持久对象的提取和和数据的加工处理上，如果用上了ORM,程序员很有可能将全部的数据提取到内存对象中，然后再进行过滤和加工处理，这样就容易产生性能问题。
在对对象做持久化时，ORM一般会持久化所有的属性，有时，这是不希望的。
但ORM是一种工具，工具确实能解决一些重复，简单的劳动。这是不可否认的。但我们不能指望工具能一劳永逸的解决所有问题，有些问题还是需要特殊处理的，但需要特殊处理的部分对绝大多数的系统，应该是很少的。
现在的问题是ORM还处于起步阶段，现有的ORM工具实现的不是很好，并且相互之间的差别太大，而熟悉一种产品是需要代价的，这样就导致大部分人多ORM工具的反感。
本人推出了自己的一条ORM工具，希望能对大家有所帮助
http://www.dotnetcoding.net
因为orm要配置xml，数据库改表结构那就是惨事。hib需要学习hql，hib速度不怎么好，一下子load了多表数据。orm调试麻烦，需要xml与代码混合观察。orm提供的模型要求我们把对象映射为关系数据库表结构，如果文档做不全或者更新不及时就很难移交程序。
我有个比较好的解决方案，使用speedframework框架，我已经使用它一年多了。
Speed 快速 J2EE 开发框架
Speedframework(
http://sourceforge.net/projects/speedframework)是一个完全基于JDBC开发的轻量级持久层框架. 它可以直接调用SQL,也可以直接对POJO进行CRUD操作,代码与ORM相当.调试方便,不用配置,内置JCS缓存,能有效降低数据库压力,它具有以下特点:
1.免配置持久层，免配置可以减少开发中配置带来的烦恼，调试带来的烦恼。
2.完全是jdbc封装操作，性能完全没问题。
3.jcs cache实现，对于数据库操作对象缓存减轻数据库压力。
4.自带分页组件，完全可以直接传入一条sql即可完成困难的分页逻辑，可以由客户自定义。
5.结合表、视图实体逻辑设计模式可以实现xp开发。
6.speed能自动识别表字段pk的自增主键，并可以返回自增字段值。
7.实现了jdbc的批处理封装，存储过程调用等jdbc api常用的封装。
8.降低了入门门槛，有利于初期开发和中后期维护，适用于开发程序员经常更换的团队。
http://sourceforge.net/projects/speedframework/
@冬冬
“还有一个问题：比如我要更新某网站的一篇文章，但只是制订改什么字段就更新那些字段，不指定的不更新（不指定的也可能已经变了），ORM怎么实现？
比如用户修改一篇文章的内容，但是不修改点击量的话，点击量应该不变，但这时候网站在运行，点击量应该是不更新，而不是用以读取的量覆盖。”
我们的这个框架能实现这个功能，不改不更新，希望对你有帮助：
http://www.macrobject.com/cn/nobject/index.htm
不推荐使用ORM：原因，业务需求变化后，需要修改数据库数据表存储过程以及Object，还要重新编译。
建议采用SP＋XML方式，需求变化后修改量最小。
Why ORM?