ORM的世界(修订版)

工作的缘故,公司希望我能够设计一个ORM产品,市面上有很多的这类产品,但考虑版权和日后我们的东东要做成平台,所以希望还是自己做。
市面上的ORM真是多啊,收集一下(不分排名):
1、ObjectSpaces
MS的东东,微软在.net 2.0的早期测试版本提供过,后期铲除了,根据ms的说法,因为和WINFS的技术有重叠(我的英文不好,翻译的可能完全错了);
个人认为设计的很经典。

2、Gentle.NET
从飞鹰的网站上搜索到的,知识浅薄,刚刚知道这个大作

3、NHiberate
这个就懒得说了,程序员都知道。

4、DataQuicker
一个国人开发的ORM,正在开发中,支持国货;

5、SmartPersistenceLayer
国人的又一佳作,对其不太了解,给个连接。

6、DataObjects.NET
老外的东西,名声也挺大。

7、
PDO
这算是我的OR 的启蒙老师了,他的网站我无法访问了,但可以访问这个,大概是旧网站吧。
觉得他的作品抽象能力很强,不盲目效仿主流产品。

8、Swallow.NET
又一个国人的骄傲了,真是形式一片大好啊。

9、XPO
国外有名公司的作品,可是我认为他沿用了JAVA中的一些老思想,没有将实体和操作分离。

10、OJB.NET
老外的,不了解。

11、ECO II (修订后补充)
borland公司在新产品中包含的重量级作品,从特性列表中看,竟然有Undo/Redo,没有具体去使用。

12、Grove.NET (修订后补充)
留言中补充的冬冬,其实前几天反编译看过,总体简洁,但功能就有待提高了。

太多了,有空再补上吧,回帖的朋友尽量推荐一些国产的东东

最后,照例我也发表一下我的看法:
1、国内如此多的OR高人,DUDU可以建立专门的栏目,将各位高人罗列出来,互相认识,互相促进;
2、建议各位高人共同学习,发表OR的专业文章,并在cnblogs中建立专门的栏目;
3、还是百花齐放的最好,不要心血来潮,要做一个“世上最好”的。

关于OR知识我想说一些浅薄的知识:
1、实体类和操作类还是分开的好,适合分布式开发,以及数据交换,太多好处了;

//不分离的例子
data.Save();

//分离的例子
dataManager.Save(data);

2、序列化支持我认为也是设计中重要考虑的问题;
3、实体的完整绑定支持也应该是重要的考虑,目前看见的很多OR都没有考虑;
绑定方面需要考虑ICustomPropertyDesc、IBindingList、IDataSource、ITypedList和视图的概念。
4、为方便界面中安全的操作实体,应该在设计中提高基础的Builder支持;
5、等想到别的再补上吧
posted @ 2005-07-03 20:18 编写人生 阅读(3978) 评论(13)  编辑 收藏

  回复  引用  查看    
#1楼 2005-07-03 21:07 | dudu      
可以建立一个OR团队Blog。
  回复  引用    
#2楼 2005-07-03 21:39 | 寒枫天伤 [未注册用户]
实体类和操作类是否应该分开,这个有待商议,一般而言ActiveRecord的形就是不分开的,不少人的认为这样更符合领域驱动开发的原则,同时,也有人指出了,实体类的设计是不合理的,一个纯的实体类不应该使用类来描述,而应该使用结构体。所以,这是一个值得争议的问题。

就目前在项目中的应用角度而言,我目前看好XPO,因为它是商业组件,售价也不高,同时,Devexpress公司的口碑是非常不错的,如果发现了问题,反馈一般可以得到立即的答复,这把O/R Mapping的组件的维护的责任分担了出去,在开发中可以更放心。同时由于XPO与Devexpress组件结合是比较好的,在数据绑定与可视化配置等特性上相较其它组件较强。

开源的组件,目前看好的是Nhibernate与Gentle.NET,其中Gentle.NET只提供了单向的映射能力:由数据库到代码。就通常所认识的O/R Mapping组件而言,Nhibernate更符合惯用的特性,但由于Nhibernate目前更新较为缓慢(前几天更新快了一阵子),BUG也不少,所以如果要在项目中采用需要冒一定的风险。而Gentle.NET虽然BUG相对较少,也有着O/R的大多数特性,但因为不支持直接的类->表的生成方式,用起来有时有许多不便之处。
  回复  引用    
#3楼 2005-07-03 22:44 | idior [未注册用户]
---
实体类和操作类是否应该分开
---
编写人生这里提到的实体和操作分离的说法有些问题.
这里的操作不是类的方法而是存储所用到的方法.如果就操作而言我认为不应该分开, 不然还叫什么oo.
但是对于存储操作显然还是分开的好. 这在广大产品中也有了体现.

现在有一个很有意思的问题, 我发现很多人反其道行之, 在orm把存储操作分离的情况下, 很多programmer却又把它放进类中,常见方法有搞一个基类 businessobject, 然后其他类继承于它.
对于这种应用我觉得是不太合适的, 这种情况比较适合于那些本身没有什么操作的纯实体类. 而如果仅仅是纯实体类, 我觉根本不需要orm.
dataset什么的就ok了.

  回复  引用    
#4楼 2005-07-03 22:48 | idior [未注册用户]
对这个东西很有兴趣,最近也很闲 想作些开发.


  回复  引用  查看    
#5楼 2005-07-04 08:33 | 双鱼座      
关于O/R Mapping,在博客园我也谈论过不少。我觉得能够说得上够实用水平的只有两三样而已。其中一样是楼主所说的XPO,另外两个便是ECOII和Grove.Net。这两个框架最主要的贡献是提供强大的工具来提供开发效率。另外还有一个框架DeClarit,更具特点:每个Entity对应一个Component,直接使用PropertyGrid进行编辑,不能不说是设计精妙。

我研究过的持久化框架不下20个,当然研究最多的还是鼎鼎有名的Hibernate.在Hibernate中,因为强调的是“持久化”的概念,所以通常都是先有POJO,后有对应的数据库结构,所以提倡“纯净”的概念。在.net中,实用是第一的,所以是否“纯净”是见仁见智的。

我认为,操作类和实体类根本不存在是否分开的问题。实体类根本不需要处理Save这样的需求,因为Save是事务相关的,实体内处理事务,显然是职责不清(天啦!又是一个水果篮问题)。操作类这个东西也根本无需与实体类一一对应,根本这就是一个活动容器,一个标准的事务类。
  回复  引用    
#6楼 2005-07-04 08:34 | neuhawk [未注册用户]
1、按照javaeye较多人的观点,po跟vo(企业架构模式里,应该是DTO)应该分开的,也就是说,跟UI绑定的是的VO而不是DTO,
不知道.net有什么好的方法PO<->V0<->UI相互转换。
2、查询, 无论如何,现在orm提供的查询是不够的,很多企业对数据
查询(分析)要求得比较强大。如果用dataset做查询,但是datagrid
->vo->po又比较难以用反射来减少代码。
3、性能,不好说,不同的应用,结果是不一样的。
4、字段变化,比较麻烦。


  回复  引用    
#7楼 2005-07-04 08:46 | neuhawk [未注册用户]
ECOII也好,Grove.Net也好,事实上,我更希望象spring对hibernate的支持一样来控制事务.castle对Nhibernate和Ibatis支持
,这点很好.
ORM 商业的我不会使用,免费但不开源的也不会,只使用开源的.
  回复  引用    
#8楼 2005-07-04 09:02 | neuhawk [未注册用户]
上面说错了:

1、按照javaeye较多人的观点,po跟vo(企业架构模式里,应该是DTO)应该分开的,也就是说,跟UI绑定的是的VO而不是PO,
不知道.net有什么好的方法PO<->V0<->UI相互转换。
2、查询, 无论如何,现在orm提供的查询是不够的,很多企业对数据
查询(分析)要求得比较强大。如果用dataset做查询,但是datagrid
->vo->po又比较难以用反射来减少代码。
3、性能,不好说,不同的应用,结果是不一样的。
4、字段变化,比较麻烦。


  回复  引用    
#9楼 2005-07-04 09:11 | AlleNny [未注册用户]
WebSharp比较好用
  回复  引用    
#10楼 2005-07-04 09:36 | neuhawk [未注册用户]
我现在的方式,跟websharp差不多,但是对于有1:n N:N关系操作时,没有orm操作方便.
  回复  引用    
#11楼 2005-07-04 19:47 | 程序人生 [未注册用户]
看见了一篇文章《小评几种O/R Mapping工具》讲的不错。

http://www.cnblogs.com/William_Fire/archive/2005/03/09/115818.html
  回复  引用    
#12楼 2005-07-19 14:04 | 易水之风 [未注册用户]
Snake.Net中的数据映射是基于DataSet对象的。DataSet 对象是 Microsoft .NET 框架中数据访问的关键部分,是可保存表、视图和关系的内存中对象。Snake.Net中的数据映射是通过定义一个描述业务实体的DataSet(如图1.1),将其所需要应用到的数据表结构定义(表以及表与表之间的关系)进行描述。然后通过构建一个业务实体类(Class)并将类内特定域(Field)映射到DataSet中相对应数据表内的字段而实现的。

Snake.Net代码包内包括以下内容:
所有代码在Eastasp.Enterprise.Core目录下,
所有需要使用到的类库在library目录下
演示事例在Eastasp.Enterprise.Core.Samples目录下
数据库脚本在scripts目录下(当前仅提供MSSQL)
目录DataBindObjectBuilder下提供了一个实体类生成工具DataBindObjectBuilder你只需要选择一个特定的xsd文件,然后按生成即可。

Snake.Net目前提供的是测试版本,近供有兴趣的同仁参考和使用
如果你在试用的过程中发现不足之处,欢迎指正。

详细情况请访问我的Blog
http://blog.csdn.net/soulroom/

下载地址
http://www.eastasp.com/download.files/products/snake.net.rar
http://download2.eastasp.com/snake.net.rar

  回复  引用    
#13楼 2007-11-24 11:53 | gallon [未注册用户]
大力举荐 Grove , 我们已经开发很多项目了, 而且里边的设计思路也应用到了asp和php。
不推荐用NH, bug太多, 学习研究可以。

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2005-07-04 11:44 编辑过


相关链接: