Question

我还没有开始ORM之旅，

因为当项目变得非常复杂时我不确定它是如何工作的。

您的意见或经历是什么？

Answer 1

这个问题有时难以回答。您之前可能听说过Object-Relational Impedance Mismatch;这是ORM工具试图解决的问题，但它充满了问题。在这种情况下，您可以在很短的时间内解决90％的问题，但是由于所有的依赖关系，每增加1％的情况似乎会在复杂性方面呈指数级增长。

ORM框架是一种抽象，在几个方面成为漏洞抽象：

涉及UDT，CTE，查询提示，临时表，窗口函数等概念的复杂查询/脚本
性能优化的查询。正如Quassnoi在他的回答中所提到的，ORM在这方面越来越好，但经常产生次优查询，有时效果非常明显。
事务管理 - 当您必须处理大批量更新时，工作单元模式只能帮助您。
跨数据库或跨服务器操作。有解决方法，但它们只是 - 解决方法。我见过的ORM没有真正处理好这个。
多表继承 - 这是实际规范化的唯一继承形式，使用纯SQL和手动映射实际上并不难，但是O / R mappers很糟糕。对于我们中的许多人来说，单表继承不是可接受的替代方案。

这些是O / R地图制作者似乎让我们失败的许多领域。话虽如此，这并不意味着O / R Mappers不适合大型项目。

在我看来，一般来说，ORM和O / R Mappers对于大型项目来说几乎是至关重要。它们可以节省大量的精力，并且可以帮助您在很短的时间内将应用程序推出门外。他们只是没有解决整个问题。您必须准备好对应用程序进行概要分析以查看ORM实际正在做什么，并且您必须准备好在情况需要时回退到纯SQL（即在上面的几种情况中）。

某些框架（例如Linq to SQL）希望您这样做并为您提供现成的工具，以便在同一连接和用于映射器“常规”职责的同一事务中执行命令或存储过程。 L2S并不是唯一允许你这样做的框架，但是有些框架更具限制性，你最终会跳过许多环节来获得你需要的东西。在选择ORM时，我认为绕过抽象的能力是一个重要的考虑因素，至少在今天。

我认为这个问题的最佳答案是：是的，它们适合大型项目，只要您不完全依赖它们。了解您选择的ORM工具的限制，在可能的情况下，将它用作90％实例中的节省时间，并确保您和您的团队了解抽象泄漏时这些实例的真实情况。

Answer 2

ORM。通过定义，是对象关系映射。

这意味着您应该将存储在关系数据库中的数据转换为面向对象编程语言可用的对象。

对象可能提供一些可能涉及数据处理和搜索其他对象的方法。

这就是问题的开始。

数据处理可以在ORM端实现（这意味着从数据库加载数据，应用对象环绕并在您使用的编程语言上实现方法），或者在数据库端实现（当数据处理命令作为查询发布到数据库中。

比较一下：

MyAccount->Transactions()->GetLast()

这可以通过两种方式实现：

SELECT  *
FROM    Accounts
WHERE   user_id = @me

进入$MyAccount

，然后

SELECT  *
FROM    Transactions
WHERE   account_id = @myaccount

进入客户端数组@Transactions

，然后$Transactions[-1]获取最后一个。

这是一种效率低下的方式，当你获得更多数据时，你会注意到它。

或者，智能ORM可以将其转换为：

SELECT  TOP 1 Transactions.*
FROM    Accounts
JOIN    Transactions
ON      Transactions.Account = Accounts.id
WHERE   Accounts.UserID = @me
ORDER BY
        Transactions.Date DESC

，但必须非常聪明ORM。

因此，“是否使用ORM”问题的答案是“我的ORM允许我在需要时向数据库发出基于集合的操作的问题的答案”出现“？

Answer 3

当项目变得更复杂时，它会更好，因为它让所有东西保持在同一抽象级别，而不是从对象跳转到SQL。我们曾经在开发应用程序时编写了我们自己的层（因为我们不能使用任何传统的ORM），并且它变得越强大，管理应用程序就变得越来越容易。

您通常会高估性能问题。它通常在不同的地方，然后你会期望。我们有一些用Python编写的badass抽象层，它工作得很好。糟糕的是url库，我们不得不在C中重写。真的，你总是可以优化查询，最后最重要的是，当你看到，当你看到性能需要它时，手工编写SQL。但在大多数情况下 - 你不必这么做。

Answer 4

这是主观的。我的答案是关于自动化ORM工具。

我对ORM工具有一个哲学上的反对理由，原因如下：
1-表不是也不一定是与业务对象的一对一映射 2- Base CRUD / Business Object代码很难写，但它对您的应用程序至关重要。我宁愿掌控并了解它。（有点NIH综合症）
3-一个新的开发人员将更容易学习传统的对象模型，而不是ORM工具创建的任何奇怪的语法。

Answer 5

您没有提到您正在使用的平台，但如果我想在不使用ORM的情况下从.NET中的数据库中读取记录，我将不得不：

读取连接字符串
打开数据库连接
针对连接打开Command对象
读取我的记录（通过对Command对象执行SQL语句）
将该记录转换为对象用我选择的语言
关闭我的查询
关闭我的连接

听起来很复杂？ ORM自动完成所有相同的事情，我只需要几行代码。此外，由于ORM了解您的数据模型，因此有时可以执行缓存和延迟加载等优化。

Answer 6

在我看来，ORM是为大型项目而构建的，旨在最大限度地减少工作量和开发时间。

但是如果您正在开发需要非常高速数据访问代码的应用程序，则需要尽可能避免使用ORM，因为ORM在您的应用程序中添加了一个新层

Answer 7

ORM是大型项目的理想选择，因为它们为数据库端的更改提供了一层保护，并加快了添加新功能的过程。如果性能成为问题，您可以使用不同的方法在遇到瓶颈的查询中获取数据，而不是手动优化应用程序中的每个查询。

Answer 8

如果您希望快速抽出网络应用程序进行客户开发并查看人们是否真正使用您的产品，那么ORM很酷。

http://www.youtube.com/watch?v=uFLRc6y_O3s

Josh Berkus讨论的最后一个话题是“失控的ORM”。请在37:20查看。

ORM适合复杂的项目吗？

8 个答案: