ORM适合复杂的项目吗？

Question

我还没有开始ORM旅行,

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

你有什么看法或经验？

Answer 1

这个问题有时难以回答.您可能以前听说过对象关系阻抗不匹配 ; 这是ORM工具试图解决的问题,但它充满了问题.在这种情况下,您可以在很短的时间内解决90%的问题,但是由于所有依赖关系,每增加1%的情况似乎会在复杂性方面呈指数级增长.

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

• 涉及UDT,CTE,查询提示,临时表,窗口函数等概念的复杂查询/脚本.

• 性能优化的查询.正如Quassnoi在他的回答中所提到的,ORM在这方面越来越好,但经常产生次优查询,有时效果非常明显.

• 事务管理 - 工作单元模式只能在您必须处理大批量更新时才能实现.

• 跨数据库或跨服务器的操作.有解决方法,但它们只是 - 解决方法.没有我见过的ORM真正处理好这个.

• 多表继承 - 这是实际规范化的唯一继承形式,使用纯SQL和手动映射实际上并不难,但O/R映射器很糟糕.对于我们许多人来说,单表继承不是一个可接受的选择.

这些是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 编写了一些出色的抽象层，并且运行得很好。最糟糕的是 url 库，我们必须用 C 重写它。实际上，你总是可以优化查询，这在最后是最重要的，当你看到性能需要它时，此时手工编写 SQL。但在大多数时候 - 你不必这样做。