请问各位都用什么ORM框架？

[RockPlus]

公司以前做的项目都比较小，对象转存到数据库用的老大自己写的一个ORM框架，以前并发量不大，应用环境也不复杂,所以使用起来没什么大问题。最近接到一个大项目，做第一期项目的时候发现了几点问题。
第一是 数据转为对象慢，我写一个测试程序。在同样的条件下，我们自己的ORM将数据转换为对象要40秒，Nhibernate只要15秒就可以了。
第二是 在并发比较大的情况下(不是非常大)数据会莫名其妙的被改掉，比如说我用多个线程多次通过该框架访问数据库后数据就错掉了。
第三是 出错了信息提示不明确，因为是内部用的，有些异常直接用try catch给隐藏起来了。
第四是 在使用的过程中有可能是ORM自身的BUG,引起程序异常，这样一边要检查上层程序，同是还要去排除底层ORM的bug，这样很浪费时间的。

鉴于以上原因，我想把底层ORM给换了,用一个成熟的第三方产品。在网上搜了一下，比较倾向于以几个产品：
1 Nhibernate
原因：用的比较多，资料也比较好找。
2 Castle ActiveRecord
原因: 不用配置对象的XML文件，这点比Nhibernate爽
3 EntityFramework
原因：微软的东西（说真的，有点不想用）
4 mybaits.net
原因：我几个搞java的朋友都说他们现在不用hibernate了都在用mybaits。
就以上这些了，因为现在公司已经写了不少代码了，想换个ORM是比较得大的决定，所以想听听各位朋友的意见，你们所在公司.net都用什么ORM框架啊？方便的话请按照以下的格式回复一下,谢谢了。
如果用朋友怕泄漏公司情况的话，也可以不按照以下格式回答，自己怎么方便，怎么说，谢谢了。

使用ORM名称:
项目规模(代码行数):
所在行业:
公司.net项目组开发人员数量:

[百世经纶一页书]

引用 141 楼 mcpll 的回复:

引用 133 楼 pig23 的回复:有些人就这样，觉得自己学linux就比windows高级，学java就比.net强，用第三方frame也不用微软的，因为总觉的windows是普通老百姓玩的，自己搞开发的肯定要用高级的东西，这种人技术我敢肯定都很烂，不管他学哪种技术，因为他没有掌握一个合格程序员最基本的素质——认清本质 严重同意

说的是大实话，一方面批评微软技术不好，另一方面又使用他的产品，这不是自己给自己扇耳光吗！》

[perock]

用DataSet

[xiaogui340]

Castle ActiveRecord 用过，对于复杂对象处理太多限制麻烦

[云草桑]

引用 83 楼 showjancn 的回复:

如果是.net系列，强列推荐用EF，最好用最新版本的。我做电力应用，基本没有问题。 这是我个人的几个观点： 1：EF只是一个ORM框架，只是解决仓储层的问题，到于有人说“ORM注定了业务逻辑和数据库的高度耦合”，其实是理解错了，ORM的O是数据对象，与表等有一定的偶合，但它从架构设计 上来说，只是仓储层的内聚设计，与业务逻辑无关（当然现在很多小系统会用它来直接替代业务逻辑对象），而真正的业务逻辑对象（按领域驱动设计来说）是领域对象，真正的的系统核心对象是领域对象，而数据对象是可变的，领域对象则相对稳定，数据对象到领域对象是通过仓储层的适配器来实现的。 2、EF等ORM框架的优势是减少开发难度及维护难度，性能上没有优势。一个好的系统可能要考虑设计与性能的平衡，只是谁轻谁重的问题。至于仓储层由于采用的ORM等技术带来的性能损耗，是可以通过底层数据库设计（如：视图、中间表、触发器等）和应用层的缓存等技术手段来进行弥补。

近期做的招行项目也是用的EF框架，性能上确实没啥优势。。

[予沁安]

Fluent nHibernate

[yuyejian]

当然是EF6啦

[zh_harry]

第一是 数据转为对象慢，我写一个测试程序。在同样的条件下，我们自己的ORM将数据转换为对象要40秒，Nhibernate只要15秒就可以了。 第二是 在并发比较大的情况下(不是非常大)数据会莫名其妙的被改掉，比如说我用多个线程多次通过该框架访问数据库后数据就错掉了。 第三是 出错了信息提示不明确，因为是内部用的，有些异常直接用try catch给隐藏起来了。 第四是 在使用的过程中有可能是ORM自身的BUG,引起程序异常，这样一边要检查上层程序，同是还要去排除底层ORM的bug，这样很浪费时间的。 兄弟基于你的情况 我建议使用自己的orm框架，有问题要迎上去改，而且这并不是大问题，都可以改 第一 语言本身的反射是很慢的，不管是JAVA还是.NET 为什么hibernate 快，是因为他用的不是反射，类似于动态代理模式，这一块你可以参考java 的asm 框架，reflectasm 可能对这块更容易理解，反射慢的问题可以解决。 第二 数据莫名其妙的被改，是因为多线程访问时，访问了共享变量，因为servlet 是单例多线程的，也有可能是dao 或业务层是单例，存在成员变量，高并发可能就会出现这个问题，也可以改，跟踪一下就可以了。 第三 提示信息可以改到日志文件中，输出所有出错信息，这个问题也不大。 第四 框架是一个不断改进的过程，这个过程是值得的。用成熟框架同样会有这样的问题，hibernate 太重了，把它的代码全看完，说实话不太现实，mybatis 要自己写SQL.并没有优势。自己写个ORM还是很不错的。 有问题可以找我492006183 QQ

[关山路遥]

引用 42 楼 microtry 的回复:

[Quote=引用 41 楼 zip117 的回复:] 我毕业到现在都用Nhibernate,还没有出现解决不了的问题. [/Quote] ORM注定了业务逻辑和数据库的高度耦合,确切的说一个业务实现只能对于一个数据结构, 连改一下数据结构都要修改程序,更不用说同时支持不同的数据结构了

改了数据结构 肯定得改程序啊 数据不是程序的操作对象吗 对象变了 程序的操作也得变啊

[duhailee]

不知道上一次在csdn发言是什么时候了。。 今天没忍住。 先回答楼主的问题。 1，我们还没用orm。 2，不过我们正准备用。候选是EF和NH。具体用哪个，我觉得问题不大，我想做到持久层尽可能的分离于业务逻辑。如此一来orm对于系统的影响会减小，以后的替换也方便。 3，看到好多说自己写的，我真心佩服他们的勇气。但我不会这么做，就算我们有足够的力气，除非是迫不得已，否则我会选择一套设计优良且开源的orm，在确实遇到瓶颈的情况下，自己修改它。重复造轮子确实并不是必要的。 还看到有人说自己写的找错容易，请允许我刻薄的说一句， 您为何不自己造个c#呢。 orm的简单功能，实现起来并不困难， 若要考虑复杂的查询，映射，缓存，事务，通用等等因素，远超出一般应用系统的复杂度。 4，据我浅薄的了解EF和Nh的差异并不那么大。也不该歧视ms，尽管我经常忍不住有这样的想法，但是就事论事而言，EF不会太差劲。其他几款也是，各有侧重点。 5，还看到反对ORM的，这个我也理解。不过我会义无反顾的使用，理由很简单，谁用谁知道。抛开学习曲线不说，任何对数据库的改变，势必要修改代码， 如果不改， 你改的就是配置文件，或者是你的存储过程之类的。想彻底不改变，是有较真精神的。 我觉得这又何苦呢， 如果要权衡看其带来的价值和效率与你付诸的代价比较， 是远大于的话， 使用是理智的选择。另外还有嘲笑orm的， 我只能呵呵了。

[jmllc]

SEE SEE ,LOOK LOOK.

[hudsonhuang]

nhibernate用过，太大了，慢得吐血 ibatis.net用过，太多配置的东西了，写起来会头昏 现在小项目用ms非常前期的东西叫grove，但是还是有点bug，而且支持的数据库不多，然后都是自己反编译原来的类库并修改的-_- 有时间学学其他orm才行

[hudsonhuang]

上面BS MS的朋友 我顺便说一个 google的chrome界面是用MS的WTL写的

[bluedoctor]

我总结各类ORM框架都有2个硬伤： 1，查询不灵活，甚至EF都不能象SQL那样灵活的查询； 2，效率不高，原因大家都知道，反射或者表达式树造成的。 如果要有一个高效灵活的ORM，那么建议你选择PDF.NET开发框架，它没有上面说的这2个问题。看看框架最新版 V5.0的查询：

string sqlInfo="";
            //下面使用　ITable_User　或者　Table_User均可
            List<ITable_User> userList =
                OQL.FromObject<ITable_User>()
                    //.Select()
                    .Select(s => new object[] { s.UID, s.Name, s.Sex }) //仅选取３个字段
                    .Where((cmp, user) => cmp.Property(user.UID) < 100)
                    .OrderBy((o,user)=>o.Asc(user.UID))
                .Limit(5, 1) //限制５条记录每页，取第一页
                .Print(out sqlInfo)
                .ToList();

            Console.WriteLine(sqlInfo);
            Console.WriteLine("User List item count:{0}",userList.Count);

详细看 一行代码调用实现带字段选取＋条件判断＋排序＋分页功能的增强ORM框架

[o笨笨猪o]

引用 163 楼 duhailee 的回复:

不知道上一次在csdn发言是什么时候了。。 今天没忍住。 先回答楼主的问题。 1，我们还没用orm。 2，不过我们正准备用。候选是EF和NH。具体用哪个，我觉得问题不大，我想做到持久层尽可能的分离于业务逻辑。如此一来orm对于系统的影响会减小，以后的替换也方便。 3，看到好多说自己写的，我真心佩服他们的勇气。但我不会这么做，就算我们有足够的力气，除非是迫不得已，否则我会选择一套设计优良且开源的orm，在确实遇到瓶颈的情况下，自己修改它。重复造轮子确实并不是必要的。 还看到有人说自己写的找错容易，请允许我刻薄的说一句， 您为何不自己造个c#呢。 orm的简单功能，实现起来并不困难， 若要考虑复杂的查询，映射，缓存，事务，通用等等因素，远超出一般应用系统的复杂度。 4，据我浅薄的了解EF和Nh的差异并不那么大。也不该歧视ms，尽管我经常忍不住有这样的想法，但是就事论事而言，EF不会太差劲。其他几款也是，各有侧重点。 5，还看到反对ORM的，这个我也理解。不过我会义无反顾的使用，理由很简单，谁用谁知道。抛开学习曲线不说，任何对数据库的改变，势必要修改代码， 如果不改， 你改的就是配置文件，或者是你的存储过程之类的。想彻底不改变，是有较真精神的。 我觉得这又何苦呢， 如果要权衡看其带来的价值和效率与你付诸的代价比较， 是远大于的话， 使用是理智的选择。另外还有嘲笑orm的， 我只能呵呵了。

说得很好！看了这之前的很多回复我都有点儿想喷的感觉，但还是忍住了，毕竟每个个体所处的环境不一样，背后的理论知识也不一样，个体是有差异的，我们应该要理解。 我使用nhibernate

[无聊的一个人啊]

个人认为Moon.Orm相当不错.性能优异、使用便捷、多数据库数据源支持、2.0原生支持、智能感知. 免费且提供代码生成器. 详情:http://www.cnblogs.com/humble/p/3320804.html

[HenryWang99888]

mark~ mark~

[lucas_123]

引用 11 楼 microtry 的回复:

于其费劲去纠结使用何种ORM,不如干脆不用, 楼主尝试这样去做: 实现一个最简单的部门信息的CURD, 如果你能做到修改数据结构而不用修改任何代码, 那么你就初步实现了业务逻辑和数据访问的分离; 再如果,修改界面的查询条件或者列表而不用修改任何代码, 那么你就初步实现了业务逻辑和界面的分离; 能做到这些,就差不多是MVC的设计模式了

支持这一想法，感觉ORM挺多余。自己搞了个项目，业务逻辑全部放在存储过程，用到的技术都是非常基础、简单的，感觉开发也挺快的。

[david_88888]

引用 35 楼 amokall 的回复:

[Quote=引用 11 楼 microtry 的回复:] 于其费劲去纠结使用何种ORM,不如干脆不用, 楼主尝试这样去做: 实现一个最简单的部门信息的CURD, 如果你能做到修改数据结构而不用修改任何代码, 那么你就初步实现了业务逻辑和数据访问的分离; 再如果,修改界面的查询条件或者列表而不用修改任何代码, 那么你就初步实现了业务逻辑和界面的分离; 能做到这些,就差不多是MVC的设计模式了 [/Quote] 绝对不用ORM，除非数据库由关系型数据库变为对象型数据库，如果那一天数据库真的变成了对象型数据库，那么ORM也就不存在了，因为程序无需在通过转换，数据库开发商或编程语言开发商会提供数据提供者，就像今天的ODBC、OLEDB、SqlClient等一样，根本就无需什么额外的转换。 综上，企图用ORM来转换关系型数据库是很可可笑和低效的事情，而且不要指望ORM可以延续到未来，对待关系型数据库就用最简单最高效的sql方式处理，每当看到别人把表都转换成对象时，我都想笑，这些对象就是多余的垃圾。

和我想的一样，但是现在ORM是主流，好多公司也都用了ORM，面试也问这个，你不会人家说你对新技术不敏感，好像跟不上时代！

[david_88888]

引用 62 楼 effun 的回复:

我很OUT，一直在用Linq To SQL，没有什么不妥。

我更OUT，一直用ADO.NET,用的挺开心

[chenruoyun]

目前正在使用ibatis.net