我在 ASP.net/SQL Server 开发环境中工作。如果我唯一关心的是速度，我应该使用参数化查询还是应该使用诸如 nHibernate 或 LINQ 之类的 ORM？
问问题
319 次
5 回答
3
大多数 ORM 支持参数化查询，因此在这方面没有区别。我会尽可能地使用 ORM 来实现，并且只在需要时通过手工制作 SQL 进行优化。
了解 ORM 的工作原理应该可以帮助您构建性能良好的代码。这样，您可以避免明显的陷阱，例如在循环中重复调用查询，例如，通过外键查询另一个表时。
于 2010-01-11T21:17:26.587 回答
3
在所有条件相同的情况下，ORM 会增加开销，因此它们一开始处于劣势。
另一方面，ORM 可能会生成比您更高效的 SQL，其中许多都带有您不必自己编写的内置缓存功能（如果它们适合您的目的，您从缓存中获得的改进可能大于您因额外开销而损失的东西）。
于 2010-01-11T21:20:22.323 回答
1
对此的答案实际上是“视情况而定”，并且需要您在自己的环境中对其进行测试以确认，但总的来说，我会说使用 ORM 工具会增加一个额外的抽象层，这可能会花费您一些开销。我想如果你真的不擅长编写 SQL，ORM 可能会更好，但在这种情况下，我只会努力提高你的 SQL 技能。
编辑：我只想补充一点，我通常不会根据性能在 ORM 与无 ORM 之间做出决定。我会根据其他因素做出选择，并在这种情况下优化我的设计。
于 2010-01-11T21:19:05.147 回答
1
如果您唯一关心的是不使用缓存的查询速度，那么您不需要 ORM，因为它的主要功能是通过消除执行本机查询的需要来简单地编码。但有时您需要使用带有 ORM 的原生查询来获得最佳速度，即使如此，抽象可能需要比手动使用参数化查询稍长的时间。
但是，如果您的查询可能会从缓存对象中受益，那么 ORM 可能会提高您的速度。
于 2010-01-11T21:21:43.880 回答
1
开销来自进行映射、跟踪更改等......，而不是查询本身。映射非常快，但是如果您在一次操作中处理 100,000 条记录，则直接 sql 会胜出。但是，如果您在操作中处理 100,000 条记录，则不应使用 ORM。
于 2010-01-11T21:28:37.190 回答