ORM仇恨者无法理解

我看过无数的文章和评论(尤其是评论),它们告诉我们ORM(对象关系映射)的概念有多糟糕,糟糕和错误。 以下是通常的声明,以及我对它们的评论:
  • “它们很慢” –映射有一些开销,但这并不严重。 您可能会拥有慢得多的代码段。
  • “它们会产生不利于性能的错误查询” –首先,它产生的查询要比常规开发人员编写的查询更好,其次–如果您使用错误的映射,则会产生错误的查询
  • “它们剥夺了您的控制权” –您可以自由执行本机查询
  • “您不需要它们,普通的SQL和XDBC很好” –不,但是我将在下一段中讨论
  • “它们迫使您使用不好的吸气剂和吸气剂” –您的实体是简单的价值对象, 在那里使用吸气剂/吸气剂就可以了 。 下面的更多内容
  • 数据库升级非常困难– ORM周围有很多工具可以简化架构转换。 许多ORM都内置了这些工具
但是,为什么首先需要一个ORM? 假设您决定不使用一个。 您编写查询并以ResultSet的形式(或使用您所使用语言的任何形式)将结果取回。 您可以在那里通过其名称访问每一列。 结果是类型不安全的类似地图的结构。 但是系统的其余部分需要对象–前端组件需要对象,服务方法需要对象作为参数,等等。这些对象是简单的值对象,并且通过getter公开它们的状态没有错。 他们没有对状态进行操作的任何逻辑,它们只是用来转移状态。 如果您使用的是静态类型的语言,则很可能在代码周围使用对象而不是类型不安全的结构,更不用说这些结构是数据库访问接口,并且您不会在前端使用它们码。 因此,您想到了一个绝妙的主意–“我将创建一个价值对象,并将结果集中的所有内容转移给它。 现在,我将数据保存在一个对象中,不需要在数据库中传递特定于接口的接口来传递代码。” 这是伟大的一步。 但是很快您就意识到这是一项重复性的任务–您正在创建一个新对象,并逐字段手动进行操作,将结果从SQL查询传递到该对象。 然后,您设计了一个巧妙的反射实用程序,该实用程序可以读取对象字段,并假定您在数据库中具有相同的列名,读取结果集并填充对象。 好吧,猜猜是什么–多年来,ORM一直在做同样的事情。 我敢打赌他们的更好,并且可以在许多您认为不需要的场景中工作。 (而且我只是简单地说明了维护本地查询的过程有多奇怪-有些将它们放在一个巨大的文本文件中(难看),而另一些则将它们放在行内(DBA现在如何优化它们?))
总结上一段–您将在项目中创建某种ORM,但是您的项目将比那里吸收的更多,并且您不会承认它是ORM。
这是提到称为commons-dbutils (Java)的实用程序的好地方。 它是将数据库结果映射到涵盖基本情况的对象的简单工具。 它不是ORM,但它执行ORM的工作–将数据库映射到您的对象。 但是基本的列到字段映射器中缺少一些东西,那就是外键和联接。 使用ORM,即使需要JOIN来获取它,也可以在“地址”字段中获取用户的地址。 这既是ORM的优点,也是主要的缺点。 * ToOne映射通常是安全的。 但是* ToMany集合可能非常棘手,并且经常被滥用 。 这部分是ORM的错误,因为ORM不会以任何方式警告您映射某个公司的所有订单的集合的后果。 您将永远也永远不需要访问该集合,但是可以对其进行映射。 我从未从ORM反对者那里听到过这样的争论,因为他们还没有达到这一点。
那么,ORM基本上是dbutils加上危险的集合映射吗? 不,它为您提供了许多所需的其他功能。 方言–您以与数据库无关的方式编写代码,尽管您可能不会更改最初选择的数据库供应商,但是使用任何数据库都容易得多,而无需每个开发人员都了解语法的罪魁祸首。 我曾经使用过MSSQL和Oracle,但与他们合作几乎没有痛苦。 另一个非常非常重要的事情是缓存。 您会执行两次相同的查询吗? 我猜不是,但是如果碰巧是在第三个方法调用的两个单独的方法中,则可能很难捕获或避免。 会话缓存来了,它将为您保存所有重复的查询,以便从数据库中获取某些行(对象)。 这里对ORM还有另一种批评–会话管理太复杂了。 我主要使用JPA,因此我无法透露其他信息,但是正确地进行会话管理确实很棘手。 都是出于很好的理由(前面提到的缓存,事务管理,延迟映射等),但是它仍然太复杂了。 您需要团队中至少有一个对特定ORM有丰富经验的人员来正确地进行设置。
但是还有二级缓存,这要重要得多。 这种事情可以使facebook和twitter之类的服务存在–将很少变化的数据填充到(分布式)内存中,而不是每次都查询数据库,而是从内存中获取对象,这快了很多倍。 为什么这与ORM相关? 因为通常可以将缓存解决方案插入ORM,并且您可以将ORM生成的对象完全存储在内存中。 通过这种方式,缓存对您的数据库访问代码变得完全透明,从而使其简单而高效。
因此,总而言之– ORM仍在做您需要做的事情,但是几乎可以肯定的是,存在10年的框架比您自己的映射器要好,并且它们在顶部提供了许多必要且重要的附加功能他们的核心功能。 他们也有两个弱点(他们实际上都说“您需要知道自己在做什么”):
  • 它们很容易被滥用,这可能导致从数据库中获取大量不必要的结果。 您可以非常轻松地创建app脚的映射,这会减慢您的应用程序的速度。 当然,拥有一个良好的映射是您的责任,但是ORM并没有真正帮助您
  • 他们的会话管理很复杂,尽管有很好的理由,但可能需要团队中经验丰富的人才能正确地进行设置
我从未见过将这两个用作反对ORM的论据,而本文开头的错误用法却经常被使用,这使我相信,对ORM狂热的人们很少知道他们在说什么。

翻译自: https://www.javacodegeeks.com/2012/05/orm-haters-dont-get-it.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值