ORM vs 传统数据库查询，它们的字段是什么？

ORM 似乎是一个快速发展的模型，有利也有弊。来自 Richard Kiessig 的超快速 ASP.NET (http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b https://rads.stackoverflow.com/amzn/click/com/1430223839):

“我喜欢它们，因为它们使我能够非常快速地开发小型概念验证站点。我可以避开原本需要的大部分 SQL 和相关复杂性，而专注于对象、业务逻辑和表示。但是，同时，我也不关心它们，因为不幸的是，它们的性能和可扩展性通常很差，即使它们与全面的缓存系统集成时也是如此（当您意识到当正确时，其原因就很清楚了配置好后，SQL Server本身实际上只是一个大数据缓存”

我的问题是：

• 您对理查德的想法有何评论？你同意他的观点吗？如果没有，请说明原因。

• 什么字段最适合ORM和传统数据库查询？换句话说，哪里应该使用 ORM，哪里应该使用传统数据库查询:)，哪种类型/大小......的应用程序无疑应该选择 ORM/传统数据库查询

提前致谢

我不同意人们普遍抱怨 ORM 性能不佳。到目前为止，我已经见过许多纯 SQL 应用程序。虽然理论上可以编写优化的 SQL，但实际上，它们通过编写未优化的业务逻辑而破坏了所有性能增益。

当使用纯 SQL 时，业务逻辑与数据库模型高度耦合，数据库操作和优化取决于业务逻辑。因为没有面向对象模型，所以您无法传递整个对象结构。我见过许多应用程序一次又一次地传递主键并从每一层的数据库中检索数据。我见过循环访问数据库的应用程序。等等。问题是：因为业务逻辑已经很难维护了，没有再优化的空间了。通常，当您尝试重用至少部分代码时，您会接受它并未针对每种情况进行优化。性能因设计而变差。

ORM 通常不需要业务逻辑过多关心数据访问。 ORM 中实现了一些优化。有缓存和批量处理的能力。这种自动（和运行时动态）优化并不完美，但它们将业务逻辑与其分离。例如，如果有条件地使用一条数据，它会根据请求使用延迟加载（仅一次）来加载它。您不需要做任何事情来实现这一点。

另一方面，ORM 的学习曲线很陡。我不会将 ORM 用于简单的应用程序，除非 ORM 已被同一团队使用。

ORM 的另一个缺点是（实际上不是 ORM 本身，而是您将使用关系数据库和对象模型这一事实），团队需要在关系和面向对象这两个领域都很强大。

结论：

• ORM 对于以业务逻辑为中心的应用程序来说非常强大，这些应用程序的数据结构足够复杂，因此拥有 OO 模型将具有优势。
• ORM 通常有一个（某种程度上）陡峭的学习曲线。对于小型应用程序，它可能会变得太昂贵。
• 基于简单数据结构的应用程序，没有太多的逻辑来管理它，很可能更容易、更直接地用纯 SQL 编写。
• 具有高水平数据库知识但在面向对象技术方面经验不多的团队很可能通过使用纯 sql 来提高效率。 （当然，根据他们编写的应用程序，可能建议团队转移焦点）
• 具有高水平 oo 知识且仅有基本数据库经验的团队很可能通过使用 ORM 提高效率。 （这里同样，根据他们编写的应用程序，可能建议团队切换焦点）