使用OR-Mapper是否有意义?

RBZ*_*RBZ 7 database nhibernate orm entity-framework linq-to-nhibernate

使用OR映射器是否有意义?

我把这个问题放在堆栈溢出处,因为这是我所知道的最好的地方,可以找到愿意提供帮助和意见的智能开发人员.

我的推理如下:

1.)SQL在哪里?

a.)在我参与的每个专业项目中,数据的安全性是关键要求.存储过程为控制访问和审计提供了一个自然的网关.

b.)生产中的应用程序问题通常可以在表和存储过程之间解决,而无需推出新的构建.

2.)如何控制生成的SQL?我信任解析树以生成有效的SQL.我在SQL-Server和Oracle中优化SQL方面有相当多的经验,但如果我再也不必这样做,就不会感到受骗.:)

3.)如果我从存储过程中获取数据,使用OR-Mapper有什么意义?

我已将存储库模式与本地通用数据访问层一起使用.如果需要缓存集合,我会缓存它.我也有在小型CRUD应用程序上使用EF的经验,并且有助于调整遇到性能问题的NHibernate应用程序.所以我有点偏颇,但愿意学习.

在过去的几年里,我们都听到很多受人尊敬的开发人员提倡使用特定的OR-Mappers(实体框架,NHibernate等......).

任何人都可以告诉我为什么有人应该转向ORM主流项目的主流开发?

编辑:http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html似乎对这个话题进行了强有力的讨论,但它已经出来了约会

另一个编辑:每个人似乎都同意存储过程将用于重型企业应用程序,因为它们具有性能优势,并且能够将编程逻辑添加到数据附近.

我看到支持OR映射器的最有力论据是开发人员的工作效率.

我怀疑ORM运动的一个重要推动因素是开发人员对剩余持久性不可知的偏好(不关心数据是在内存中[除非缓存]还是在数据库上).

ORM似乎是本地和小型Web应用程序的优秀节省时间.

也许我所看到的最好的建议来自client09:使用ORM设置,但使用存储过程来处理数据库密集型的东西(当ORM看起来不够时,使用AKA).

E.J*_*nan 4

我多年来一直是一名专业 SP,并认为这是进行数据库开发的唯一正确方法,但我完成的最后 3-4 个项目是在 EF4.0 中完成的,没有 SP,并且我的工作效率得到了提高真是令人惊叹——我现在可以用几行代码完成以前需要一天时间才能完成的事情。

我仍然认为 SP 对于某些事情很重要(有时您可以通过精心选择的 SP 显着提高性能),但对于一般的 CRUD 操作,我无法想象会回到过去。

所以对我来说简短的回答是,开发人员的生产力是使用 ORM 的原因——无论如何,一旦你克服了学习曲线。