Question

我喜欢ORM工具，但我经常认为对于大型更新（数千行），在

之类的内容加载，更新和保存似乎效率低下

UPDATE [table] set [column] = [value] WHERE [predicate]

会提供更好的表现。

但是，假设出于性能原因想要沿着这条路走下去，那么你将如何确保内存中缓存的任何对象都能正确更新。

假设您正在使用LINQ to SQL，并且您一直在使用DataContext，那么如何确保您的高性能UPDATE反映在DataContext的对象图中？

这可能是“你没有”或“在DB上使用触发器来调用丢弃缓存的.NET代码”等等，但我很想听到这类问题的常见解决方案。

Answer 1

你是对的，在这种情况下使用ORM加载，更改然后保存记录效率不高。我的过程就是这样的

1）早期实现使用ORM，在我的例子中是NHibernate，完全是

2）随着开发的成熟，确定性能问题，其中包括大量更新

3）将那些重构为sql或SP方法

4）使用Refresh（object）命令更新缓存的对象，

我的一个大问题是通知其他客户更新已经发生。在大多数情况下，我们已经接受了一些客户端是陈旧的，无论如何都是标准的ORM使用情况，然后检查更新/插入时的时间戳。

Answer 2

大多数ORM还具有有效执行大量或“批量”更新的工具。无状态会话是Hibernate for Java中可用的一种机制，显然可以在NHibernate 2.x中使用：

Answer 3

ORM非常适合快速发展，但你是对的 - 它们效率不高。它们非常棒，因为您不需要考虑将内存中的对象转换为表中的行再返回的基础机制。但是，很多时候ORM没有选择最有效的方法来做到这一点。如果您真的关心应用程序的性能，最好与DBA合作，帮助您设计数据库并适当调整查询。（或至少自己理解SQL的基本概念）

Answer 4

批量更新是一个值得怀疑的设计。有时它们似乎是必要的但是，在许多情况下，更好的应用程序设计可以消除批量更新的需要。

通常，应用程序的其他部分已经逐个触摸每个对象; “批量”更新应该在应用程序的其他部分完成。

在其他情况下，更新是在其他地方处理的前奏。在这种情况下，更新应该是后续处理的一部分。

我的一般设计策略是重构应用程序以消除批量更新。

Answer 5

ORMs不会像手工制作的SQL一样高效。期。就像手工制作的汇编程序会比C＃更快。表现差异是否重要取决于很多事情。在某些情况下，更高级别的抽象ORM可能使您的价值高于潜在的更高性能，在其他情况下则不然。

遍历与目标代码的关系可能相当不错，但正如你正确地指出存在潜在问题。

话虽如此，我个人认为ORms在很大程度上是一种虚假经济。我不会在此重复，只是指向Using an ORM or plain SQL?