几种 Dotnet ORM 库的比较

Posted on 2006-12-30 22:13 Riceball LEE 阅读(6064) 评论(36) 编辑收藏网摘

到底哪一种最好呢？必须考虑序列化和反序列化的速度要快，占用内存小，并且不能有内存泄漏，容易使用。唉，难找啊。
我粗略看了下几种的ORM，请各位大侠不吝指教，小弟感激为盼。

国内：

Web Sharp: http://websharp.sf.net
License: BSD License, GNU Library or Lesser General Public License (LGPL)
.Net 版本： .Net Framework 2.0

入门文档写得不错，清晰，上手容易，同时也一下子就说清楚了WebSharp的意图以及覆盖范围。不过框架的层次就语焉不详了。

Websharp的目标，是开发一个开源的基于Microsoft.Net的轻量级的应用软件系统开发框架，包含以下内容：
* 一个轻量级的O/R Mapping框架
* 一个轻量级的AOP框架
* 一个轻量级的ServiceLocator，主要目的是为整合不同服务端技术的客户端编程。

Websharp ORM主要特点是使用Attribute作为描述映射的方法，简单明了，并且，对开发人员来说，只有PersistenceManager、Query、Transaction等极少数接口需要掌握，上手快，使用非常方便。只需要普通的类就可以进行O/R的转换，不需要从指定的类上派生。

遗憾：
无自动代码生成器，要手工写实体类。

Kanas.net: http://www.cnblogs.com/barton131420
License: GNU LESSER GENERAL PUBLIC LICENSE
.Net 版本：.Net Framework 1.1

优势：
* 它的设计思想也是使用Attribute作为描述映射的方法，同时多了一个 CodeGen IDE附加工具，使用XML格式文件作为输入，自动生成类的代码，不过VS2005下不能使用。并提供了基本NUnit一些测试【应该顺便测试下运行效率】。
* 限制特定查询条件它通过内建的 Constrant 系列对象实现，据作者说可以可以满足90%以上需要的查询条件，使用简单【建议作者提供一个复杂查询的例子】。也可以自行派生，如：查询月日是否相同，定义的DayConstrant类。

遗憾：
* CodeGen 工具没有提供源码，并且该工具必须在VS2003 IDE下使用，不爽【建议最好有一个能独立运行的CodeGen工具】。
* 帮助文档极不友好， Kanas.Framework 的基本描述，设计目标，覆盖范围都没有，帮助文件里类的说明用词晦涩难懂，还不如直接看源代码。上手难。
* 实体类必须从 BizObject 上派生（实际上它的BizObject也只是一个壳，所有的数据都是交由 DataCell 控制）

NBear: http://Nbear.org
License: BSD.license
.Net 版本：.Net Framework 2.0
用到的第三方库： Castle Project

实体类必须定义成接口从 IEntity 派生，同样使用 Attribute。
提供NBear.Tools.EntityGen.exe 工具从数据库表和视图生成对应的实体类，目前只支持SqlServer和Access。
入门文档极多，上手并不太难，感觉该库的侧重点是Web结合方面，很是不错，正和我的需要，就是不知道速度
性能和内存占用如何。
可惜没有对自身框架做描述和解释的文章。文档大多以教程为主，说明如何用。

NBearV3 SDK.chm 无法看到内容，报告脚本出错，装的是IE7内核。似乎是从源代码自动生成的文档。
NBearV3TotoursCN.zip 只是教程，以及为啥取名未NBear【汗，这个谁关心啊，取名字嘛作者的权力】，关键是架构说明。依然只是简单提了一句，还是说的使用的是IEntry, 没发现什么变化：NBear的核心包括一个泛型、强类型的的数据持久化接口、一组接口式的Entity定义组件、高性能 XML/JSON序列化支持、服务工厂、分布式服务队列和Web组件。

最新提供了一个简单的NBear的读写性能测试，可以参考： http://nbear.org/Modules/Articles/Detail.aspx?i=33

NObject: http://www.macrobject.cn/cn/nobject/index.htm
Requirements: .NET Framework 1.1 or 2.0
License: 目前还是商业许可。
NObject O/R Mapping 框架使您能完全通过面向对象的方式访问数据库数据。NObject O/R Mapping 框架包含了 OQL.NET，一套基于 C# 和 VB.NET 等原生 .NET 语言的强类型对象查询语言 (OQL, Object Query Language)
附带的 Macrobject CodeAuto 代码生成器能帮您自动生成所有的持久类代码。
性能待查。

iBATIS.NET

The iBATIS Data Mapper framework makes it easier to use a database with Java and .NET applications. iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools.

To use the iBATIS Data Mapper, you rely on your own objects, XML, and SQL. There is little to learn that you don't already know. With the iBATIS Data Mapper, you have the full power of both SQL and stored procedures at your fingertips.

Are you interested but want to know what others have said? Well, first see the various articles and books that have covered iBATIS and read some of our user feedback. Then, learn how to simple it is to use the iBATIS Data Mapper by reading the .NET Quick Start Guide!

http://ibatis.apache.org/dotnetdownloads.cgi

NickLee.ODRM和演示源代码下载基于 IBATIS

License: Apache License 2.0.

国外
NHibernate for .NET
Release date: 03.11.2006
Requirements: .NET Framework 1.1 or 2.0
还未看，从java的Hibernate移植过来，如果没有利用CLR的特色，只是为了移植而移植，那就～～

DevExpress XPO
License: 商用
还未看

http://www.howtoselectguides.com/dotnet/ormapping/
这篇文章不错，告诉你如何选择ORM工具，以及列举出了国外常见的ORM工具【English】：

Feedback

#1楼  回复 引用 查看

2006-12-30 22:43 by 史海涛

DonNet ?or DotNet?

#2楼  回复 引用 查看

2006-12-30 23:11 by Teddy's Knowledge Base

谢谢对NBear的介绍。不过，你对NBear的描述有一些错误：

首先，你文中的所有介绍，应该都是NBearV2时的情形，V3对比V2有一个质提升改进，教程、文档，也比V2要好，最新版本v3.4.10，更多文档还在整理制作中。

其次，博客园的主站点完全没有使用NBear，每隔一段时间的休克，应该还是服务器资源紧张和网络爬虫造成的。因此，这和NBear应该没有关系。

关于NBear的最新信息，请参考：http://nbear.org">http://nbear.org

#3楼  回复 引用 查看

2006-12-30 23:15 by 浅水滩

我的选择：NHIBERNATE + SPRING.NET + SPRING.WEB

#4楼  回复 引用 查看

2006-12-31 00:02 by ZergTant

NHIBERNATE我用过，效率太低了，一个复杂查询用了3分钟没出结果
一直以为是别的问题，后来手写sql，10秒不到就出来了，所以以后再也不用了
也许是我水平问题，不知道你们遇到过么

#5楼  回复 引用

2006-12-31 00:11 by anonymous[未注册用户]

try IBatis.Net 半ORM的东西,上手快,其中的cache做的不错

#6楼  回复 引用 查看

2006-12-31 08:09 by JesseZhao

喜欢Nbear，IBatis没有用过，去看看

#7楼  回复 引用 查看

2006-12-31 09:06 by Jason Cui

作者写这篇文章是为了误人子弟么？

#8楼  回复 引用 查看

2006-12-31 09:12 by freetofly

看了你的文章之后，怀疑
你用过Nbear么？
不是把别的ORM框架当做Nbear了把
博客园没有用Nbear框架
而且Nbear支持目前大部分流行的数据库
何来只支持微软的数据库一说？
文档帮助相当详细，只不过是英文而已

#9楼 [楼主] 回复 引用 查看

2006-12-31 09:17 by Riceball LEE

@Teddy's Knowledge Base
多谢，我12月初上站点没有看到关于本身架构的说明解释文档，回头我再看看，

@freetofly
的确，没有用过，只是看了看它帮助，我说的是它的CodeGen工具只支持SqlServer和Access,这是它帮助里面说的，如果有错误请指出来。

@Jason Cui
如果有错误请指出来。你要骂可以，但是你得指出俺的错误所在，俺一定虚心受骂，否则怀疑你的RP.

#10楼  回复 引用 查看

2006-12-31 09:18 by Boler Guo

等着DLINQ吧，VS2007中将是最好的O/R Mapping 方法。

#11楼  回复 引用

2006-12-31 09:19 by 嘿嘿[未注册用户]

IBatisNet
www.ibatis.org
还有一个从ibatisnet扩充的ODRM
http://www.cnblogs.com/Files/mail-ricklee/ODRM.part1.rar
http://www.cnblogs.com/Files/mail-ricklee/ODRM.part2.rar
ODRM构架模式优点:
Object/DataSet Relational Mapping(对象/数据集关系映射)模式是在开源ORM映射的基础上结合NickLee.UIFactory和NickLee.Web.UI综合而成的一种灵活，快捷，简单的.net开发模式。因为其结合.net 的数据对象DataSet和ORM的优点，所以命名为Object/DataSet Relational Mapping
整合了以下优点
1.UI的灵活性
可以使用.net或者任意的三方控件，提高客户体验
2.对象化的业务处理
虽然UI层数据填充采用DataSet的方式，但业务处理的时候，可以通过NickLee.ODRM转化为有数据的对象实体，进行处理
3.清晰，快速的访问数据，以及注入攻击的防范
通过IBatisNet原始的机制，并修改了QueryForDataSet,QueryForOracleDataSet，利用IBatisNet在xml中书写清晰sql语句的作用和事务机制，使sql能完整地层现在xml中，以便于开发人员处理和修改。并有效的防止注入攻击。
通过QueryForDataSet,QueryForOracleDataSet，实现了ORM中对象和xml关系的分离，整个业务可以不同步对象和xml中的<resultMaps>和<alias>(当然，原始的IBatisNet机制我们没有修改，开发人员可以选择使用IBatisNet原始的ORM机制也可以使用我们扩充的QueryForDataSet,QueryForOracleDataSet模式)
4.对象实体，DataSet,Hashtable的互相转换
通过ODRM可以实现灵活的三个对象之间互相转换，这样无论任何数据，都可以以其中一种模式存在并可转
化为其他模式

#12楼  回复 引用 查看

2006-12-31 09:20 by Jason Cui

我是从来不怕别人怀疑我的人品的，只是你写这篇错误百出的文章还放到首页，不知道意义何在？

目前业界最成熟可靠的，还是NHibernate。先这种文章可以先到Google上搜索一下，可以省很多麻烦。

#13楼  回复 引用 查看

2006-12-31 09:27 by 随心所欲

WilsonORM.
有工具，功能好，分页函数，扩展性好

#14楼 [楼主] 回复 引用 查看

2006-12-31 10:01 by Riceball LEE

@Jason Cui
哪里错误了？我说了NHibernate不稳定了么？我只是分别列举ORM工具出来。如果你这么欣赏NHibernate,那么请列举出在WebStress工具面前NHibernate的内存表现和速度表现。除非你让数据说话，你的偏爱不一定是所有人的。
我写这个的目的，就是希望做过这个ORM工具性能评测的人出来说说，如果要俺测试那么我首先要装，要懂该ORM，然后还要自己编写测试代码，哪有这么多时间，时间紧啊。

#15楼  回复 引用

2006-12-31 10:08 by sunriseyuen[未注册用户]

现在这种人极多，大概看几个框架或几个ORM共用了半小时或是几小时，然后就开始评价，这些框架或ORM是人家经过N个月以上的时间写成的，未必都合适你用，但起码他是在某方面是适用的。

#16楼 [楼主] 回复 引用 查看

2006-12-31 10:32 by Riceball LEE

我的目的，文章的头就解释得很清楚了，俗话说，不怕不识货，就怕货比货。

@sunriseyuen
又一个跳出来说空话的，某方面，某方面又是哪一个方面？真是些大爷啊。
再说空话就删贴了。

#17楼 [楼主] 回复 引用 查看

2006-12-31 10:38 by Riceball LEE

@嘿嘿
谢谢，我会瞧瞧的。暴露一个dataset，直接于Datset交互？这样速度倒是挺快的，就看对象化的开销了。

#18楼  回复 引用 查看

2006-12-31 10:43 by Wisdom-zh

干脆再加上我们的 Macrobject NObject/OQL.NET 吧:
http://www.macrobject.com/">http://www.macrobject.com/
只是目前是商业产品, 不过未来会开源的!

#19楼  回复 引用 查看

2006-12-31 10:44 by Jason Cui

年轻人火气这么大干嘛？这样很不好。

#20楼  回复 引用 查看

2006-12-31 10:57 by Anders小明

推荐DLinq完全不一样的ORM，NHibernate也是有自己的优势的

#21楼  回复 引用 查看

2006-12-31 11:43 by JesseZhao

DLinQ 确实很期待，一会去看看

#22楼  回复 引用

2006-12-31 11:47 by Alec[匿名][未注册用户]

其实大家重在讨论，每一种工具都要自已新自体验过才有发言权，对吧？大家没必要好像非要把什么好用什么不好用强加给谁，只有适合自已的才是好用的。我也用了NHibernate，可能是效率是低了一点，但也没有到无法忍受的地步。只是觉得NHibernate写配置文件难写，处理关系的时候修改我觉得太麻烦。所以，现在看看有没有其他更好的选择。至于NHibernate我想本身应该是值得用的，他在JAVa下的大名可能大家都知道吧。

#23楼  回复 引用 查看

2006-12-31 11:50 by 双鱼座

OK，该我说话了。
非常感谢你介绍Kanas.net框架，并接受你的评价。不过我还是要解释一下：

* CodeGen 工具没有提供源码，并且该工具必须在VS2003 IDE下使用，不爽。
答：正在做vs2005的版本，估计2007年元月会发布出来。至于原始当然也一并发布。VS2003不发布源码的原因是用到一个商业控件。VS2005的版本将使用VS2005SDK，所以不需要任何第三方控件了。

* 帮助文档极不友好， Kanas.Framework 的基本描述，设计目标，覆盖范围都没有，帮助文件里类的说明用词晦涩难懂，还不如直接看源代码。上手难。
答：接受批评。新版本中将尽量改进。不过发布版本中的文档都是用NDoc生成的，新版本将提供更多的PDF文档。

* 实体类必须从 BizObject 上派生（实际上它的BizObject也只是一个壳，所有的数据都是交由 DataCell 控制）
答：这的确是一个限制，而且我短期内不会放弃这个限制。速度以及透明性依赖这个限制。关于这个限制的细节，我已有相关的文章介绍。

* 限制特定查询条件它似乎需要从 Constrant 类派生实现的，如查询月日是否相同，都要定一个DayConstrant类，俺觉得这样太过于繁琐了。
答：我发现你可能有所误解，仅仅这个抱怨我不能接受。在我的框架中已经提供了你所可能需要的90%以上的查询条件，并且使用了比目前现有所有的框架都更方便的使用方式。我文档中所举的DayConstraint的例子只是为了说明如何扩展“约束子”。

对于目前开源的或者商业的ORM框架很多，我不适合作评价。不过我觉得我框架中实现的两点，还没有看到哪个框架很好地实现。
1.关于约束子。我认为条件这个东西必须一个独立的，可以传递的、可以运算的对象。例如，我可以将一个约束子作为一个对象附加在用户相关的上下文中，作为“数据权限”的依赖，以实现更灵活的权限控制，例如可以进行权限的“方面控制”。这个Henry的组件也实现了同样的功能。但是，NHibernate没有，NBear也没有。我非常推崇的商业框架DataObjects也没有。
2.关于数据集。我不知道是否有人使用Kanas.net提供的从BizObjectList到DataTable间的切换？当然，Kanas.net是通过Kanas.Commons这个命名空间提供的，这个功能并不是必须的，也并不是仅支持Kanas.net的BizObject的列表。但是提供了一套可扩展的DataTable生成机制。本来按最初的设计，我的AppContext会提供DataSet的管理器，只可惜没有实现，且新版本中也将不会实现。也许会在2.1或者更晚的版本实现。这样会大大减轻手工编码的压力，并且提供了非常灵活的可扩展性，可以为某个对象的列表提供多个视图生成器、多个属性编辑器、多个对象编辑器。2.0版将等待asp.net 2.0 ajax的发布，提供基于Ajax的对象编辑器框架实现。
不过，这一切与ORM本身并没有关系，所以并不会象其他某些框架那样将一些Web的逻辑放到ORM本身的框架中。
最后说一下，我本人并不喜欢ORM这个概念，在本文中接受这个概念也是因为某种妥协。个人不接受这个来自java的、完全无厘头的概念。

#24楼  回复 引用

2006-12-31 12:05 by Lupin[匿名][未注册用户]

最近在用NBear做一个项目，
发现NBear最好的一个地方就是，修改数据库几乎完全不会对Service层有影响，而且添加了VS2005插件后，那真是爽。之前用NetTiers，修改一次数据库那是十分烦恼的事情！
不过NBear也有它不足的地方，比如：
１，Attribute还不够多，比如不支持默认值（我相信很快就出来了）
２，不专心（IOC，MVP，Web什么都有，还不如专心做好ORM）

#25楼  回复 引用

2006-12-31 20:55 by 路过[未注册用户]

推荐Eunge的DQ2，虽然很久没有更新了，不过应付小项目绝对绰绰有余了

#26楼 [楼主] 回复 引用 查看

2007-01-01 00:21 by Riceball LEE

@双鱼座
感谢您的细致解答，不过有些小小的疑问，还望赐教：
“在我的框架中已经提供了你所可能需要的90%以上的查询条件，并且使用了比目前现有所有的框架都更方便的使用方式。”
到底是什么方式？你是指：Kanas.Framework.Filters 下的RapidHunter? 通过类的派生实现？我看了下源代码似乎不是使用select sql语句而是一个一个的过滤，这样效率也不高啊。或者你是指通过预先构建的 Constraint 对象完成90%的查询条件(我估摸应该是这个)，那怎么个用法？请明示！粗略看了下constraint的源代码，感觉生成Select语句的过程蛮复杂的，时间和内存开销不大么？

建议再做一个能独立运行的CodeGen工具，好方便俺这种人——不喜欢IDE的，除非是设计界面的时候，平时就喜欢用文本编辑器整。

其实俺最担心的还是返回某个数据集的记录列表的问题，如果全部对象化时间开销太大，消耗内存也是很大的，但是如果直接暴露出数据集dataset返回，就怕
无法约束其值和字段（比如有些字段是内部的，不想暴露出来），万事都有代价的。

从DataTable上派生的目的是为了什么？如果数据全部放在内存里，速度固然提高了，但是内存占用却未免太大，这样并发访问数量难免受影响，最好是在尽量考虑到节约内存的前提下，提升速度，才完美。

管它什么名称，只要知道ORM就是 Object <-> Database 的技术就行了，交流嘛，只要大家都能明白，就OK。（小声说下，其实俺对什么AOP，IoC这些提法也很是感冒。）

呵呵，期待能早日看到您的2.0版本。

@Wisdom-zh
ok, 希望早日开源，不过性能评测，有空的时候做一下，也好方便别人选择。

#27楼  回复 引用 查看

2007-01-02 00:18 by 双鱼座

@Riceball LEE
不好意思，这两天一直呆在重庆，没有机会上网。
关于查询条件，你的估计是对的。你在源代码中应该可以发现Constraint的接近20个派生类。不过Kanas.net并不鼓励你直接使用这些类，而是使用运算符的方式，这是上帝赐给C#的，当然要用上。当然，使用这些运算符需要与生成的代码Domain对象结合，当然，Domain也仅仅是一个包装器。
select或者其它的sql语句的生成的确很复杂，但是你不需要内在问题，也不必担心效率问题。这里因为不存在任何IO操作，所以效率问题并不是需要关注的，反而灵活性和可扩展性(做到真正与关系数据库无关)最重要。
RapidHunter是可有可无的，在2.0中换了一个面目。它解决的所谓“模糊查询”的问题，这个功能是留给运行时的而不是设计时的，无需扩展。

独立的CodeGen在vs2003下是提供了，但在vs2005下不再提供，原因是我会加入菜单命令，直接从Visio文件/PowerDesigner文件/数据库Schema导入Erm文件。我不知道你所谓的独立运行的CodeGen是指什么？命令行工具么？如果是个可视化的设计器，那岂不是和VS2003中一样要自己写一个IDE？当然，Kanas.net并不介意你通过文本编译器来编辑Erm文件。在IDE下，CodeGen的过程是完全自动的，不需要你做任何操作。

对象化的问题我也正在思索，对内存的开销是我从一开始就考虑的问题。如果你要一次性装载50万行数据，我相信你会同意那完全不适合使用任何对象化的方式。在我的框架中，持久化的过程已经做到了“尽可能迟”。学习Linq的设计思想，我在2.0中实现了装载数据的“尽可能迟”。

提供DataTable的切换是为了实现完全自动的、可配置的界面视图，毕竟对于无连接的数据访问，DataTable的实现是最好的，目前没有必要再去另外实现。

再次感谢你对这个框架的兴趣，以及你所提出的宝贵意见，任何一个意见我都会非常珍惜。

#28楼  回复 引用

2007-01-02 11:02 by string[未注册用户]

不知道用什么，太杂了，只好自己写了个简单的

#29楼  回复 引用

2007-01-02 12:46 by upzone[匿名]

年轻人,火气不要大哦

#30楼  回复 引用

2007-01-03 11:03 by sun[匿名][未注册用户]

我曾经用NHibernate做过项目（在一个省的某系统单位推广），发现性能真的很是问题，我觉得可能用IBatisNet会好很多；也许真是我的水平有问题，但如果一种技术太难，太难于使用，我想某种程度上也是不可取的；所以我以自己的经验建议大家用IBatisNet

#31楼  回复 引用

2007-01-03 11:05 by sun[匿名][未注册用户]

@ZergTant
有同感，我的qq是3913109，现在用ror,vs2005,ibatisnet，有空多交流，谢谢

#32楼 [楼主] 回复 引用 查看

2007-01-06 08:15 by Riceball LEE

@双鱼座
hehe, 元旦去玩了.

是的，就是命令行工具，ermToSrc, 将erm文件翻译成src.

是啊，对于Grid(data Collection)，采用ORM效率太低，将每一行转为Object，然后在表现的时候又要转，这样既耗时间又耗空间，只有在编辑某条记录的时候，才能显出ORM的威力。如果完全对象化，将会得不偿失，当然这只是我个人看法。

#33楼  回复 引用

2007-01-08 15:47 by play[未注册用户]

>是啊，对于Grid(data Collection)，采用ORM效率太低，将每一行转为Object，然后在表现的时候又要转，这样既耗时间又耗空间，只有在编辑某条记录的时候，才能显出ORM的威力。如果完全对象化，将会得不偿失，当然这只是我个人看法。

1、的确是个人看法
2、而其中的“太低”又是一个相对描述，所以不妨可以理解为“足够低”——但针对什么样的应用而言是“足够低”什么样的应用又不是“足够低”呢？
那么，依据这一推理，我们应该得出结论：

究竟如何评价 ORM，以及一个具体的 ORM 产品，首先要用它来针对不同应用进行分析和评测，然后看它对这一应用而言是否有意义。
其次，当我们对足够多的主流应用进行了这样的科学的、相对客观的评测之后，我们才能根据结果得出结论：ORM在...情况下不适用于...等应用，适用于...应用，然后总结：就xxx情况普遍而言，ORM 是/不是一个好东西。

>对于Grid(data Collection)，采用ORM效率太低，将每一行转为Object，然后在表现的时候又要转
呵呵，DataSet就不必转么？
只不过是强类型的 object 罢了——先不说 Typed DataSet，DataSet 难道就不是 Object 么？这是 DataGrid 的实线机制决定的。
也就是说，设计 DataGrid 的目的就是为了便于把各种 Object 都能方便的 List 出来。如果硬要要求不“转”，那就别用 DataGrid，呵呵

很多朋友讨论 ORM 的时候容易走极端。而也有很多朋友追求和思索 ORM 的时候也在走极端——天然而言，ORM 的基础在于用 OO 甚至仅仅是 object based 方式编程，这已经能给我们带来足够的方便了。
那么，究竟方便是来自于代码自动生成？还是来自于“面向对象的思维方式更贴近于我们自然的思维方式”这样教条主义的理论？

不是。显然，问题的根源还不在 ORM——它只是帮助我们从面向 DB 和结构化的编程转向 OO 的开发方式之间的一个桥梁和工具而已。可见，问题的根源在于 OO。

所以，ORM 好用与否，首先当然与你所使用的 ORM 产品密切相关。
而普遍影响我们使用 ORM 效果如何，恰恰是我们对 OOA/D/P 的应用能力。

而从另外一个角度来看，ORM 不能解决所有的问题，也并不是 ORM 本身的问题，而是 OO——显然是因为 OO 不能解决所有的问题，或者说有些场合不适合用 OO。

那么，问题的根源很清楚了：
如何做好 OOA/D ？如何设计好一个系统，满足需求的同时，尽可能协调好开发成本、维护成本之间的关系？这恰恰是引入 OO 的真正原因。如果需求决定不便于使用 OO，那就不用。否则就要用好 OO，利用面向对象的一些特性平衡好开发速度/成本和维护成本，平衡好可复用性与可维护性之间的关系。
何必苛求 ORM？——
何必以 ORM 本来就不解决的问题指责它（你的需求决定了不适合用OO来解决问题为何还用ORM？）？
何必花那么多精力去追求实现“完美”的ORM方案，而把本来仅仅是为了在实现我们的目标（更好的oo系统设计）的过程中提供一个比较好的推动的工具，当成了我们最终的目标，而本末倒置？

hehe，不是很好的理解了 OO 的威力或者还不能很好的发挥它的威力的朋友，不妨多花一些时间去深入了解 oo；
在 ORM 终极之路上浪费了太多精力的朋友也不妨平心静气想想，我们究竟是用信息技术解决具体应用问题还是为了解决技术问题而研究技术？什么时候是一个平衡点？设计出那么复杂的ORM甚至framework，后果是学习成本很高，值得么？——当然，我相信从学习和研究的角度很值得。但如此就不要浪费精力和别人争个面红耳赤——大家目的都不同，甚至讨论基础都不同，有什么好争的，浪费时间。

#34楼  回复 引用

2007-01-08 16:10 by play[未注册用户]

再老调重弹一个例子（我的ORM用了多少年了，我最关注的是把握好重量与灵活之间的平衡——因为我很明确我的ORM的目的，不曾偏离）：

无论有没有ORM，无论你是OO分析设计和开发还是仅仅 object based，
首先静下心来反思一下，看看自己做分析设计的时候，如何设计出数据结构的？

方法一：
先用oo的方法分析业务领域，建模，然后根据最后的 class diagrames 结合一定的数据库设计策略、优化策略等来建表

方法二：
管它三七二十一，一边考虑业务模型，一边建表，之后再用 ORM 或者手工编写表对应的 model 类

如果是方法一，恭喜你，只需要一个恰当的 ORM 工具，之后建表时在数据库设计策略、优化策略等基础上结合这一工具对建表的一些特殊要求和策略，今后你使用 ORM 会比较轻松。

如果是方法二，也没问题——但不要强求ORM能够自动理解如何将你的表转换为理想的对象模型——能够得到 Model Class 不错了。

有人或许跳出来说：我就是先建表也没影响后面建对象模型！是的，那是你运气比较好，或者经验比较丰富，默认的在建表的时候已经结合 OO 策略进行了一定的考虑。但如果以后的设计能够更加“清醒”，有意识地这么做，效果一定会更好。

ORM 究竟是什么？代码生成工具？
基于某种数据访问/持久化模型甚至运行在某种框架基础上的，结合了一定的O-R或R-O映射关系规则及其编辑器的，可能还加了代码生成器的工具集合！
也就是说，离开了这些工具、编辑器，它的核心是一种数据访问/持久化模型，配合一定的O-R/R-O映射实现策略。

所以，流行的 ORM 基本都是这两种路线：
1、轻量级：依赖某种策略或策略+用户配置文件自动从数据库创建Class，以生成代码为主。好不好用，取决于你的建表与OO平衡的水平如何，策略配置水平如何；
2、重量级：又有两种。一种，希望一次性解决根本问题，提供用OO的方式设计的工具甚至语言，然后自动建表；另外一种，把ORM往framework方向扩展——严格来说应该是framework，ORM是其中的一个主要功能。

我个人倾向：学习和研究，走HQL类路线；工作中解决实际问题，走轻量级路线，以代码生成为主。
然后，用在HQL等学习中的收获——如何协调好OO和数据结构设计之间的关系——不断用在使用轻量级的ORM工具之前（也就是说用来建表），一则实战这些经验，二则从ORM之外弥补轻量级ORM的不足。

为何？重量级ORM这条路不是走不通，是非你我之辈能够简单理解和跟上的。
学习要继续，生活也要继续。
于是，我自己的 ORM 目标很明确：
1、保持轻量级
2、精简：仅针对数据访问层，以确保最大的灵活性——不是ORM提供的功能灵活，而是架构灵活，使用方式灵活；
3、支持事务、支持“热插拔”（不喜欢这个词，但很多人喜欢这么说）更换不同的数据库，甚至持久化方式，支持多个库（暂时把跨库事务交给业务逻辑层）
4、具体语言无关：尽量不使用语言特性，支持ASP、JSP、PHP，VB，VC，C#等等。如果有必要，为特别的版本定制模板即可
5、结合代码生成工具使用，但也可以不用：本来的目的就是为了提高开发效率，提高质量（生成的代码不必重复测试）。而核心是数据访问模型，是工作方式，手写代码又如何？
6、架构灵活：因为精简到模型级别，不同语言下可以实现。那么，我把针对不同语言的部分分离出来交给代码生成器甚至模板解决。而使用的时候，就可以根据需要在不同模板中扩展自己的一些特殊需求（例如，有项目大量依赖DataSet，那就为Model模板加入Convert2DataSet()方法）。从而达到既轻量，又灵活的目的。
于是，在日常工作中，逐渐积累一些模板和DAC类（不同DAC能够解决不同的数据库服务器、不同的数据访问方式如是否通过存储过程、不同的持久化方式）即可。

我心态很平稳，因为我的目的很明确
朋友们，你呢？

#35楼  回复 引用

2007-01-08 16:21 by play[未注册用户]

关于 ORM 与 MIS，楼上朋友恰恰说错了：

一般的MIS系统中，除OLAP类查询外，自动生成的代码能够解决表现层外60-90%，甚至95%的工作量，已经很不错了。

有些MIS系统，业务间的关联比较复杂，但在生成的原子级别的方法基础上很轻松就可以“搭建”出各种业务逻辑，也很方便了。

而最大的好处，不在于是否可移植到其它数据库，不在于生成了多少代码，其实恰恰是：生成的这些代码不会像人工编写的那样，那么容易出错，需要严格测试。
节约了大量的测试成本、维护成本，提高了系统的质量。
加上开发过程中，因为生成代码节约的开发成本——综合而言，这些才是ORM的使用效果的最好体现！

用来解决企业应用，尤其中小型企业应用，恰恰是它的最佳战场。如果是门户网站和高性能应用——往数据库中批量存入10000条数据，究竟是一个Insert Into快，还是foreach objectList，对每个object.Save()快？对商品统计，取出在指定期间销量最大的，用SQL快还是遍历object进行排序来得快？

这本来就是oo与否的问题，与ORM无关。

2007年了，这类问题就不要再拿出来浪费时间了（好像2003-2004年讨论最多），呵呵