如果你对ORM的“优势”有兴趣，并且想知道为什么要使用ORM进行管理/客户端操作，那么这些理由是什么呢？
尝试每个答案只列出一个原因，以便我们可以看到哪个原因被投票选为最佳理由。
为什么你应该使用ORM？
131
- Simon Munro
10
4如果你想要一个投票，你应该将它变成一个维基页面。 - frankodwyer
1如果您想要一个投票，请将其设为Wiki。 - cletus
21那么缺点呢？ - Brian Matthews
5没有勺子。真的，这里存在一个问题：性能。如果你不需要通过ORM来执行数据库查询，那么优化过程会更加简单。(我并不是在抱怨 - 最近刚刚转到了ORM，我基本上对它感到满意；对于通用目的，ORM是最好的选择；但是如果您需要性能，保留一些更接近底层的查询方式) - Piskvor left the building
2@UğurGümüşhan，在我看来，使用ORM的主要好处是让开发人员更高效地工作，通过让他们使用与应用程序其余部分相同的语言和面向对象编程范例。存储过程无法提供这种效果，因为它们需要开发人员使用RDBMS存储过程语言编写代码。因此，它们不能像ORM一样完成所有任务。 - Bill Karwin
显示剩余5条评论
16个回答
97
使用ORM最重要的原因是可以拥有一个富有对象导向的业务模型，同时能够将其存储，并且快速地针对关系型数据库编写有效的查询。就我而言，除了你能编写高级类型的查询之外，我并没有看到使用良好的ORM与其他生成的DAL相比真正能给你带来任何优势。
我想到的一种查询类型是多态查询。简单的ORM查询可以选择数据库中的所有形状。你会得到一个形状集合，但每个实例都是根据自己的鉴别器为正方形、圆形或矩形。
另一种类型的查询是一次性从数据库中获取一个对象及其一个或多个相关对象或集合。例如，每个形状对象都返回其顶点和边缘集合。
很抱歉，我不同意其他人的观点，但我认为仅靠代码生成本身不足以理由去使用ORM。你可以编写或查找许多良好的DAL模板用于代码生成器，这些模板没有ORM所具有的概念或性能开销。
或者，如果你认为使用ORM不需要知道如何编写良好的SQL，那么我再次不同意。可能在编写单个查询的角度来看，依赖ORM更容易。但是，对于开发人员不理解他们的查询如何与ORM以及它们转换为的SQL一起工作时，使用ORM很容易创建性能较差的例程。
拥有适用于多个数据库的数据层可能是一个好处。虽然我没有经常依赖它。
最后，我必须重申，根据我的经验，如果您不使用ORM的更高级查询功能，则有其他选项可以解决剩余的问题，学习成本更低，CPU周期也更少。
噢，对了，一些开发人员发现使用ORM很有趣，所以从保持开发人员快乐的角度来看，ORM也是不错的选择。=)
我想到的一种查询类型是多态查询。简单的ORM查询可以选择数据库中的所有形状。你会得到一个形状集合，但每个实例都是根据自己的鉴别器为正方形、圆形或矩形。
另一种类型的查询是一次性从数据库中获取一个对象及其一个或多个相关对象或集合。例如，每个形状对象都返回其顶点和边缘集合。
很抱歉，我不同意其他人的观点，但我认为仅靠代码生成本身不足以理由去使用ORM。你可以编写或查找许多良好的DAL模板用于代码生成器，这些模板没有ORM所具有的概念或性能开销。
或者，如果你认为使用ORM不需要知道如何编写良好的SQL，那么我再次不同意。可能在编写单个查询的角度来看，依赖ORM更容易。但是，对于开发人员不理解他们的查询如何与ORM以及它们转换为的SQL一起工作时，使用ORM很容易创建性能较差的例程。
拥有适用于多个数据库的数据层可能是一个好处。虽然我没有经常依赖它。
最后，我必须重申，根据我的经验，如果您不使用ORM的更高级查询功能，则有其他选项可以解决剩余的问题，学习成本更低，CPU周期也更少。
噢，对了，一些开发人员发现使用ORM很有趣，所以从保持开发人员快乐的角度来看，ORM也是不错的选择。=)
- Chuck
4
4说得好。虽然原帖确实是在寻找“优点”而不是“缺点”，但我见过一些因为不理解ORM使用方式而创建的可怕SQL语句。对我来说，最大的好处在于简单的CRUD事务，这是事务性系统中DAL代码的大部分。我认为你在纯ORM和其他生成的DAL方法之间太过挑剔了。我认为任何有助于在对象和数据库之间转换的东西都可以被视为ORM，这只是一个不同的操作模型。 - Doug Lampe
1@Doug - 我认为我想要的区别是，一个简单的DAL仅包含生成的CRUD SQL，而ORM包含许多更多的抽象，例如导航属性，集合持久性，专用查询语言，缓存等。鉴于您的观察，更好地陈述我的观点的方法可能是，虽然使用ORM的更多功能可以让您实现更快，但绝不能忽视这些功能的工作原理。也许因为ORM的抽象泄漏比大多数其他抽象更多。（http://en.wikipedia.org/wiki/Leaky_abstraction） - Chuck
1请进一步阐述：“如果您没有使用ORM的更高级查询功能，则有其他选项可以解决剩余的问题。” 此外，作为Hibernate创建者的Gavin King说：“实际上，像Hibernate这样的系统是有意设计为“泄漏的抽象”，以便在必要时可以轻松混合本地SQL。ORM抽象的泄漏是一种特性，而不是错误！”-- https://www.reddit.com/r/programming/comments/2cnw8x/what_orms_have_taught_me_just_learn_sql/ - jungle_mole
- 这已经过时了。当时，ORM具备所有功能（缓存、查询、批处理等）。在我看来，基于对象的多态查询是唯一一个代码生成（显式ADO映射）无法轻松提供的ORM功能。
- 虽然有些有用的漏洞是故意留下的，但也有必要的恶习和高级功能，这在ORM中创造了一个高学习曲线。因此，我的答案是使用代码生成而不是ORM，除非您需要高级查询。 *) 现在，ORM的种类已经足够多样化，适合您团队的正确功能集可能已经存在。我们现在喜欢Linq2DB。
63
加速开发。例如，消除重复的代码，如将查询结果字段映射到对象成员，反之亦然。
- Bill Karwin
3
4重复的代码很糟糕，但是你可以建立一个抽象层来消除这种情况。例如，你可以创建一个表/查询结果对象，它将返回行，然后你可以对其进行操作。ORM似乎会将行拆分为单独的类实例，而不是按照数据库选择的抽象方式，即表/查询结果的行。我并不是说这意味着ORM不好，但我不确定这一点是否足以使用它们的原因。 - Benjohn
@Benjohn，我同意ORM解决方案将单个行视为对象，而RDBMS将一组行视为实体。在RDBMS思维方式下可以做一些在OO思维方式下无法做到的事情。 - Bill Karwin
这就像是为了使用后备箱而购买整辆汽车一样，有很多方法可以避免重复的工作。 - mohas
60
使数据访问更为抽象和可移植。ORM实现类知道如何编写特定于供应商的SQL，所以您无需自己编写。
- Bill Karwin
6
68虽然我同意这是ORM的一个特性，但我认为使用情况相当有限。我过去十年从未使用过除了MySQL和SQLite之外的任何东西。我认为对于大多数开发人员来说，这可能是一个非常罕见的需求。 - troelskn
45我同意，我使用过许多关系型数据库管理系统产品，但每个项目通常只使用一到两种。因此，可移植性并不是抽象化SQL最实际的价值所在。我认为许多ORM用户仅仅是想避免完全编写SQL代码。 - Bill Karwin
2供应商们一直推出新版本/功能...只需要一些厉害的人来编写方言并轻松升级即可！ - dotjoe
5典型的无用回答，我不知道为什么它被标记为好答案，看起来提问者只是试图向他的老板辩解应该使用ORM :) 我更想问的问题是你在使用Hibernate时会遇到哪些问题 http://stackoverflow.com/questions/6477170/why-im-scared-to-use-hibernate - user310291
2@user310291：OP并没有询问问题或陷阱，他询问使用ORM的好处。当然，有利有弊，但他询问的是优点。坦白地说，我很惊讶这个答案被接受并得到了这么多赞，因为我不认为这是ORM的主要优势。 - Bill Karwin
1ORM 到 SQL 就像 jQuery 到 JS。方便，但你并没有得到整个图片，并且依赖于其他人希望他们做得正确。 - DanMan
14
支持在数据访问层中封装面向对象的业务规则。您可以使用首选的应用程序语言编写（和调试）业务规则，而不是笨重的触发器和存储过程语言。
- Bill Karwin
4
2你不想把业务规则放在数据库里吗？这是使用数据库的好处之一：多个客户端可以使用DBMS提供的相同接口。如果大量的接口逻辑被锁定在特定客户端的ORM代码中，它就不在数据库中，其他客户端也无法使用它。这会导致前台和后台之间的断裂（一个客户端的模型与另一个客户端的模型不一致）。 - Benjohn
1@Benjohn，我倾向于将简单的业务规则放入数据库中，但是更复杂的规则不容易以声明性约束形式表达。例如，“客户第一次从同一品牌购买三条裤子以上，整个订单打9折。”你会如何将这个业务规则放入数据库中（请记住，涉及存储过程的答案往往不够优雅）？ - Bill Karwin
现在已经是2020年了，我没有看到任何人再使用存储过程。那么你的观点还站得住脚吗？ - ospider
我认为我的观点是人们不使用存储过程，而是使用应用程序代码。你有不同的理解吗？ - Bill Karwin
12
生成基本CRUD操作的样板代码。一些ORM框架可以直接检查数据库元数据，读取元数据映射文件或使用声明性类属性。
- Bill Karwin
1
1http://karwin.blogspot.com/2009/01/why-should-you-use-orm.html - Andrew Breksa
9
由于你正在开发一个抽象的应用程序，因此可以轻松地转移到不同的数据库软件。
- MattF
7
65做了 30 多年的数据库工作，我从未被要求做过这件事情。 - HLGEM
7没意味着不可能！ :) - Matt Fenelon
4@HLGEM这意味着你正在限制客户的选择。实际上可能会发生这种情况，在仅有3年web应用程序工作经验中，我们使用ORM构建了可移植的软件。 - Alfabravo
2如果您想在内存数据库上运行测试，这可能会对您有所帮助。 - Carlos Parraga
2同一软件的多个实例可能使用不同的数据库。但实际上将现有数据从一个数据库软件移动到另一个数据库软件的情况非常罕见。而且即使发生这种情况，许多ORM实际上也无法帮助您完成此操作。 - jlh
显示剩余2条评论
5
在我看来，开发的快乐就是使用ORM。ORM可以将SQL中许多底层的东西抽象出来，从而简化了代码：源文件更少，架构变更也不需要花费数小时的维护。
目前我正在使用ORM，它加速了我的开发过程。
- curiousdork
4
这样你的对象模型和持久化模型就能匹配。
- cletus
1
1也许让你的持久性对于你的对象模型来说更加透明。 - S.Lott
3
为了最小化简单 SQL 查询的重复。
- tim912
3
我翻译的结果如下：
我之所以研究这个，是为了避免使用 VS2005 的 DAL 工具（模式映射、TableAdapters）生成的代码。
我一年多前创建的 DAL/BLL 在我构建它的目的上运作良好，直到有人开始利用其中一些我不知道存在的生成函数时（导致出现问题）。
看起来它将提供比来自 http://wwww.asp.net 的 DAL/BLL 解决方案更直观和更清洁的解决方案。
我曾考虑过创建自己的 SQL Command C# DAL 代码生成器，但 ORM 看起来是一个更优雅的解决方案。
- phsr
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接