实体框架?nhibreate?见识一下另一个为实战而生的Orm

Question

为什么放着开源的Nhibernate和微软官方的EF不用，要用你这个ORM呢？
基本上能写出这个ORM算是水平不错，但是选择用你这个框架的人就属于愚蠢的人

Answer 1

EF是开放源代码的，我不知道你是否开源，但是从你的描述看，要想在广泛的测试用例下取得比EF更好的性能基本不可能，因为你除了丢弃了一些你认为EF中你觉得实现得费劲的功能以外，没有看到你为性能优化而采用任何措施。

Answer 2

我那里说了五倍,不过绝对成倍数.自己测试吧
 
呵呵,5.0之前全开源了,5.0步步开源,你也可以加入获取开源.
给你们测试代码
 http://www.cnblogs.com/humble/p/3307492.html给你开源地址
http://www.cnblogs.com/humble/p/3323161.html

Answer 3

给全面的介绍地址http://www.cnblogs.com/humble/p/3320804.html邮件联系:
qsmy_qin(at)163.com

Answer 4

提几点建议，希望楼主能考虑一下：
1、高性能不应该停留在高效的数据转换这个层次，更重要的是提供配套的Cache机制。
2、易用性不应该是BiggerThan这类东西，.NET2.0同样可以使用lambda Expression，主要是vs编译器版本的支持，实现一套Expression花不了多少时间。
3、ORM如果仅仅用来替代SQL，个人认为意义不大。
另外有一点个人经验，ORM如果只支持的单表SQL查询，有利于自动化的实现，有利于基于Cache的性能优化，而且使用也会更简单。

Answer 5

 1.内置cache
2.这个后半句,我可真不统一.不过可以在2.0使用,有一个开源的
3.不是为了替代sql
4.你说的都有.

Answer 6

个人感觉，做.NET的很少有人真的关心性能问题，有的那几人都有自己的一套方案。
而对于其它人，一般不会有人冒着“不稳定”的风险使用第三方的类库，除非你能不可替代的解决一般人的问题。

Answer 7

说实话，一直对ORM这种东西不怎么感冒，感觉好像.net这边，稍微觉得自己有点水平的人都会写一个ORM来显示自己的能力。但是实际情况是，除了开发者本人，真实生产敢用这种框架的团队或者说企业，是少之又少。小公司基本是使用成熟的大公司ORM框架，有点技术实力的公司如果需要的话会根据自己的需求写一个ORM。

Answer 8

一看就知道一个没见过世面的新手，居然把别人的博客叫做官方论坛，博客和论坛的区别都没搞清楚。
至于速度，肯定没有Dapper的高，如果仅仅和EF、nhibreate去比较，那不能说明它的效率，因为任何轻量级的第三方框架速度上都可以超过复杂的EF。你有本事我手写SQL的执行效率去比较，如果速度几乎一样，那才能说明效率高，Dapper就可以做到。

Answer 9

我相信大多数人写ORM都是为了解决实际问题。不知道什么时候Emit效率一定高于代码生成了，呵呵。只要不是频繁使用反射，效率问题都不应该出现数据转换这一块。

Answer 10

一看就知道一个没见过世面的新手，居然把别人的博客叫做官方论坛，博客和论坛的区别都没搞清楚。
至于速度，肯定没有Dapper的高，如果仅仅和EF、nhibreate去比较，那不能说明它的效率，因为任何轻量级的第三方框架速度上都可以超过复杂的EF。你有本事我手写SQL的执行效率去比较，如果速度几乎一样，那才能说明效率高，Dapper就可以做到。
用了之后,再说它的性能如何,给你们测试代码了,你们也不测试.实际求实地说话才是做东西.

Answer 11

谁说我的实体映射用EMIT反射了?不知道情况就不要信口开河.

Answer 12

一看就知道一个没见过世面的新手，居然把别人的博客叫做官方论坛，博客和论坛的区别都没搞清楚。
至于速度，肯定没有Dapper的高，如果仅仅和EF、nhibreate去比较，那不能说明它的效率，因为任何轻量级的第三方框架速度上都可以超过复杂的EF。你有本事我手写SQL的执行效率去比较，如果速度几乎一样，那才能说明效率高，Dapper就可以做到。Dapper确实可以 有人测过 总体速度不错  不知道为什么Entity framework 测试起来速度不佳

Answer 13

我说的是Dapper，你的既然是代码生成可能就是硬编码了

Answer 14

 
EF,生成model,也叫硬编码?

Answer 15

EF,生成model,也叫硬编码?我只是说可能，EF的DB frist仅仅是生成model，并没有生成数据转换代码。