为什么要使用ORM？[关闭]

113

如果您要激励为什么要使用ORM来管理/客户的“优点”，原因是什么？

尝试使每个答案保持一个原因，以便我们可以将投票结果视为最佳原因

database  orm 
— Simon Munro
source
3
如果您想进行民意调查，应该将其
— 设为
如果您要进行民意调查，请使其成为Wiki +1
— cletus 2009年
16
那骗局呢？
— Brian Matthews
4
也没有汤匙。不，确实存在一个缺点：性能。当您不必通过ORM时，优化数据库查询要容易得多。（我没有抱怨-最近切换到 ORM，我对此很满意；对于一般目的，ORM是可行的方法；但是如果您需要性能，可以保留一些方法来更接近金属对象）
— 皮斯克沃（Piskvor）在2010年
2
@UğurGümüşhan，恕我直言，使用ORM的主要好处是使开发人员能够使用与其他应用程序相同的语言和OO范例进行编程，从而提高他们的生产力。当存储过程以RDBMS存储过程语言编写开发人员代码时，存储过程将无法提供这种功能。因此，他们无法完成ORM可以做的所有事情。
— 比尔·卡温

Answers:

53

使数据访问更加抽象和可移植。ORM实现类知道如何编写特定于供应商的SQL，因此您不必这样做。

— 比尔·卡温
source
61
虽然我同意这是ORM的功能，但我建议用例是相当有限的。除了MySql和sqlite之外，我十年来从未真正使用过任何东西。我认为对于大多数开发人员来说，这可能是非常罕见的要求。
— troelskn
40
@troelskn：我同意，我已经使用了许多RDBMS产品，但是每个项目最多只能使用一两个。因此，可移植性并不是抽象SQL的最实际的价值。我认为许多ORM用户只是想完全避免使用SQL进行编码。
— 比尔·卡温
2
供应商一直在推出新版本/功能...只需要一些很棒的人来编写方言即可轻松升级！
— dotjoe 2010年
5
典型的无用答案我想知道为什么它被标记为好答案，好像那个问这个问题的人只是想向老板证明他应该使用ORM :)我的问题是您将在Hibernate中遇到什么样的问题stackoverflow.com/questions/6477170/...
— user310291
2
@ user310291：OP并没有要求任何问题或陷阱，他要求使用ORM的好处。当然有优点也有缺点，但他要求有优点。坦白说，我很惊讶这个答案被接受并且得到了像它一样多的支持，因为我不认为这是ORM的主要好处。
— Bill Karwin 2011年
83

使用ORM的最重要原因是，您可以拥有一个丰富的，面向对象的业务模型，并且仍然能够存储它并针对关系数据库快速编写有效的查询。从我的角度来看，与您可以编写的高级查询类型相比，优质的ORM与其他生成的DAL相比，没有任何真正的优势。

我正在考虑的一种查询类型是多态查询。一个简单的ORM查询可能会选择数据库中的所有形状。您会得到一系列形状。但是根据其区分符，每个实例都是正方形，圆形或矩形。

另一种查询类型是在单个数据库调用中急于获取一个对象以及一个或多个相关对象或集合的查询。例如，返回每个形状对象，并填充其顶点和边集合。

很抱歉在这里与其他许多人不同意，但是我不认为代码生成本身就是与ORM一起使用的充分理由。您可以为代码生成器编写或找到许多不错的DAL模板，这些模板没有ORM的概念或性能开销。

或者，如果您认为不需要知道如何编写好的SQL来使用ORM，那么我也不同意。从编写单个查询的角度来看，依靠ORM更容易。但是，使用ORM，当开发人员不了解其查询如何与ORM及其转换成的SQL一起工作时，创建性能差的例程太容易了。

拥有适用于多个数据库的数据层可能是一个好处。不过，这不是我不得不经常依靠的人。

最后，我必须重申，根据我的经验，如果您不使用ORM的更高级的查询功能，那么还有其他选项可以解决剩余的问题，而这些问题的学习量较少，CPU周期也较少。

哦，是的，有些开发人员确实发现与ORM一起工作很有趣，因此从让开发人员满意的角度来看，ORM也很不错。=）

— 卡盘
source
1
说得好。虽然最初的发布者确实专门寻找“优点”而不是“缺点”，但我已经看到一些不了解您使用ORM的影响而创建的可怕SQL。对我来说，最大的好处是简单的CRUD事务，这是事务系统DAL代码中的大部分。我认为可以帮助您在对象和数据库之间转换的任何事物都可以视为ORM，这只是一种不同的操作模型。
— Doug Lampe
1
@Doug-我认为我所追求的区别是，一个简单的DAL所包含的内容几乎不仅仅是生成的CRUD SQL，而ORM包含了更多的抽象，例如导航属性，集合持久性，专用查询语言，缓存等。-一种更好的方法根据您的观察来说明我的观点可能是，虽然确实可以使用ORM的更多功能使您更快地实现，但对这些功能的工作方式一无所知是绝对不能接受的。也许是因为ORM的抽象泄漏最多。（en.wikipedia.org/wiki/Leaky_abstraction）
— Chuck
请对此进行详细说明：“如果您不使用ORM的更高级的查询功能，则还有其他方法可以解决剩余的问题”。另外，正如hibernate的创建者gavin king所说：“的确，像Hibernate这样的系统是有意设计为“泄漏抽象”的，因此可以在必要时轻松地混入本机SQL。ORM抽象的泄漏是一个功能，而不是错误。 ！！” - reddit.com/r/programming/comments/2cnw8x/...
— jungle_mole
1）这很旧。那时，ORM具有所有功能（缓存，查询，批处理等）。恕我直言，基于对象的多态查询是代码生成（显式ADO映射）无法轻易提供的唯一ORM功能。2）尽管故意留下了一些有用的漏洞，但也有一些必要的弊端和高级功能在ORM中创造了较高的学习曲线。因此，我的答案是使用代码生成代替ORM，除非您需要高级查询。*）目前，ORM种类繁多，可能为您的团队提供了正确的功能集。我的团队现在喜欢Linq2DB。
— Chuck
60

加快发展。例如，消除重复代码，例如将查询结果字段映射到对象成员，反之亦然。

— 比尔·卡温
source
3
重复的代码非常糟糕，但是您能否构建一个可以消除这种情况的抽象？例如，您可以有一个表/查询结果对象，该对象将为您提供返回的行，然后您就可以使用这些行。ORM似乎将行分成单个类实例，而不是进入数据库选择的抽象，即查询结果的表/行。我并不是说这意味着ORM不好，但是我不确定仅此一个是使用它们的原因。
— 约翰2014年
@Benjohn，我同意ORM解决方案将个别行视为对象，而RDBMS将行集视为实体。在RDBMS思维方式中，有些事情是您可以在OO思维方式中无法完成的。
— Bill Karwin 2014年
这就像购买一辆整车只是为了使用后备箱一样，有很多方法可以避免重复工作
— Mohas '18
15

在数据访问层中支持业务规则的OO封装。您可以使用首选的应用程序语言编写（和调试）业务规则，而不是笨拙的触发器和存储过程语言。

— 比尔·卡温
source
您是否不想在数据库中包含业务规则？没错，这是数据库的好处：多个客户端可以使用DBMS提供的相同接口。如果许多接口逻辑被锁定在特定客户端的ORM代码中，则该逻辑不在数据库中，而其他客户端也没有使用它。提示前端办公室的后台休息（一个客户模型与另一个客户模型不一致）。
— 约翰2014年
1
@Benjohn，我倾向于将业务规则简单地放入数据库中，但是在声明性约束中不容易形成更复杂的规则。例如，“客户首次从同一品牌购买三双以上的休闲裤时，即可获得整个订单10％的折扣。” 您将如何将该业务规则放入数据库中（请记住，涉及存储过程的答案很笨拙）。
— Bill Karwin 2014年
现在是2020年，我再也看不到有人使用存储过程了。那你还站着吗？
— ospider
我认为我的观点是人们不使用存储过程，而是使用应用程序代码。你了解不同的东西吗？
— Bill Karwin
8

您可以轻松迁移到其他数据库软件，因为您正在开发抽象。

— 马特·费伦隆
source
41
在过去30多年的datbase工作中，我从来没有一次要做过。
— HLGEM
4
并不意味着不可能！:)
— Matt Fenelon 2010年
2
@HLGEM表示您正在关闭客户端的选择。实际上可能会发生，在仅3年的webapps工作中，我们已经使用ORM构建了便携式软件
— Alfabravo 2010年
1
如果您想在内存数据库中运行测试，您可能会发现它很有用
— Carlos Parraga
同一软件的多个实例可能使用不同的数据库。但是实际上很少将现有数据从一种数据库软件转移到另一种数据库软件。而且，这样做的时候，许多ORM实际上并没有为您提供帮助。
— jlh
4

IMO，发展幸福。ORM提取了您在SQL中要做的许多裸机操作。它使您的代码库变得简单：更少的源文件需要管理，而架构更改不需要数小时的维护。

我目前正在使用ORM，它加快了我的开发速度。

— 好奇鸟
source
3

我正在研究它的原因是为了避免从VS2005的DAL工具（模式映射，TableAdapter）生成的代码。

我一年多以前创建的DAL / BLL（对于我为其构建的产品）运行良好，直到其他人开始使用它来利用某些生成的功能（我不知道那里有没有）

与http://wwww.asp.net的DAL / BLL解决方案相比，它看起来将提供一种更加直观，更简洁的解决方案。

我当时正在考虑创建自己的SQL Command C＃DAL代码生成器，但ORM看起来是一个更优雅的解决方案

— 丹·麦克莱恩
source
2

查询的编译和测试。

随着ORM工具的改进，通过编译时错误和测试更容易更快地确定查询的正确性。

编译查询有助于帮助开发人员更快地发现错误。对？对。之所以可以进行编译，是因为开发人员现在正在使用其业务对象或模型而不是仅SQL字符串或类似SQL的语句在代码中编写查询。

如果在.NET中使用正确的数据访问模式，则很容易对内存集合中的查询逻辑进行单元测试。这可以加快测试的执行速度，因为您不需要访问数据库，无需在数据库中设置数据甚至不需要启动完整的数据上下文。[EDIT]这并不像我认为的那样正确。内存中的测试可能会遇到难以克服的挑战。但是我仍然发现这些集成测试比往年更容易编写。[/ EDIT]

今天，这肯定比几年前提出这个问题时更有意义，但是只有我经验丰富的Visual Studio和Entity Framework才是这种情况。如果可能，请插入您自己的环境。

— Chuck
source
1

95％的时间都提取了sql，因此团队中的每个人都不需要知道如何编写特定于数据库的超高效查询。

— 杰瑞德
source
1

我认为这里有很多好处（可移植性，易于开发/维护，专注于OO业务建模等），但是当试图说服您的客户或管理人员时，所有这些都归结为您使用可以节省多少钱一个ORM。

对典型任务（甚至可能正在进行的更大的项目）进行一些估算，您（希望如此）将获得一些难以忽视的开关参数。

— 安德斯·菲耶斯塔德（Anders Fjeldstad）
source
0

使用代码记录模板的.net层

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

为什么还要编码可以生成的东西。

— o
source
啊。我们在一个大型商业项目中使用了Net Tiers，因此强烈建议您不要使用它。问题在于它是不可组合的。是否要查询Foo和Bar对象？您不能编写联接，必须对所需的每种对象类型分别发出查询。这导致对数据库的大量调用，这可能会破坏性能和原子性。不好，不好，不好。远离。
— Judah Gabriel Himango 2011年
0

说服他们，在进行更改时您将节省多少时间/金钱，而不必重写SQL，因为ORM工具将为您做到这一点

— zmf
source
0

我认为一个缺点是ORM需要在您的POJO中进行一些更新。主要涉及模式，关系和查询。因此，您不打算在模型对象中进行更改的情况可能是因为它在项目或黑白客户端和服务器上的更多共享中被共享。因此在这种情况下，您需要将其分为两个级别，这将需要额外的努力。

我是一名Android开发人员，正如您所知，移动应用程序通常规模不大，因此分离纯模型和受Orm影响的模型的这种额外工作似乎并不值得。

我知道这个问题是通用的。但是移动应用程序也包含在通用保护伞内。

— 谢兰德拉·辛格·拉瓦特（Shailendra Singh Rajawat）
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.