EF vs NHibernate vs Drapper ORM

Jor*_*lis 2 nhibernate orm entity-framework

我想了解哪个ORM性能快?

  • NHibernate支持2级缓存,我们可以将其性能与EF或Drapper进行比较吗?
  • EF Code First看起来很有前景,但我们是否为EF提供内置的2级缓存支持?
  • 不太了解Drapper ORM

有人可以解释一下这个ORM的优缺点,以及选择哪个应用程序性能提升.

Bre*_*ias 24

"大型"ORM工具(例如EF或NHibernate)的问题在于(夸大?)99%的开发人员不知道如何掌握如何使其工作; 他们没有时间弄清楚如何让它表现出色.更糟糕的是,使这些工具正常运行通常归结为具有胜任的SQL /数据库设计和调优技能 - 这削弱了ORM的主要卖点.

在我看来,Level 2缓存的问题被一个使用不当的ORM引入的其他性能损失所黯然失色.似乎大多数使用ORM的项目都做得不好(以及设计数据库的工作很差),这使得2级缓存有点没有实际意义.

因此,像Massive或Dapper这样的微型ORM工具(后者被Stack Overflow使用)非常有吸引力:

  • 与宏ORM不同,开发人员不会花费数月时间学习如何使用它们.每个微ORM都不到一千行代码(犯罪!).这可能需要多长时间才能理解?
  • 开发人员拥有的额外时间可以专注于获得更多的SQL掌握,他们需要学习如何使用宏或微型ORM.

需要明确的是,一个使用良好的宏ORM是一件好事.您是否拥有经验丰富的员工以确保其使用良好?

最重要的是:如果您认为全面的ORM会安全地隐藏数据库的复杂性,那么几乎可以肯定您会被误解.如果我有一个选择,我会选择微型ORM.不要误会我的意思,我认为EF和NHIbernate非常酷,而且我很喜欢使用它们 - 我只是说你需要管理自己的期望.

  • 你的回答可以归结为"我对ORM并不是很了解,但无论如何我都对它们有很强的看法".99.9%的开发者不堪重负?真?或者只是你? (8认同)
  • 我几点同意他的看法.我现在正在使用实体框架,我觉得我不知道如何工作以确信以后不会出现任何问题......正如他所说的......我们没时间看看它是怎么回事应该表演. (8认同)
  • 我真的不同意NHMNnate执行需要花费很多精力.单独的第一级缓存(会话)可以带来很大的性能优势,而且没有任何额外的配置.使用Fluent NHibernate或NHibernate中的新映射代码,开始使用它会容易得多.您对ORM使用不当和数据库设计不佳的评论对于人们使用的任何内容都会保持一致 - 大多数开发人员不会查看项目的源代码,无论是1000行还是10万行...... (3认同)
  • 我什至在生产环境中也使用 Dapper。它完美地工作。非常不复杂,也非常快! (3认同)
  • 答案很好地说明了imo。纯粹就 EF 而言,我见过的绝大多数项目都浪费了大量时间来使事情发挥作用。当最终确定推荐的解决方案时(即清零关系对象),很难相信。 (2认同)