database 为什么要使用 ORM？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/448684/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why should you use an ORM?
提问by Simon Munro
If you were to motivate the "pros" of why you would use an ORM to management/client, what would the reasons be?
如果您要激励为什么要使用 ORM 来管理/客户端的“优点”，原因是什么？
Try and keep one reason per answer so that we can see what gets voted up as the best reasons
尝试并为每个答案保留一个原因，以便我们可以看到哪些被选为最佳原因
采纳答案by Bill Karwin
Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.
使数据访问更加抽象和便携。ORM 实现类知道如何编写特定于供应商的 SQL，因此您不必这样做。
回答by Chuck
The most important reason to use an ORM is so that you can have a rich, object oriented business model and still be able to store it and write effective queries quickly against a relational database. From my viewpoint, I don't see any real advantages that a good ORM gives you when compared with other generated DAL's other than the advanced types of queries you can write.
使用 ORM 的最重要原因是，您可以拥有丰富的、面向对象的业务模型，并且仍然能够存储它并针对关系数据库快速编写有效的查询。从我的角度来看，除了您可以编写的高级查询类型之外，与其他生成的 DAL 相比，我没有看到一个好的 ORM 给您带来的任何真正优势。
One type of query I am thinking of is a polymorphic query. A simple ORM query might select all shapes in your database. You get a collection of shapes back. But each instance is a square, circle or rectangle according to its discriminator.
我想到的一种查询是多态查询。一个简单的 ORM 查询可能会选择数据库中的所有形状。你会得到一组形状。但是每个实例根据其鉴别器是正方形、圆形或矩形。
Another type of query would be one that eagerly fetches an object and one or more related objects or collections in a single database call. e.g. Each shape object is returned with its vertex and side collections populated.
另一种类型的查询是在单个数据库调用中急切地获取一个对象和一个或多个相关对象或集合的查询。例如，每个形状对象返回时都填充了它的顶点和边集合。
I'm sorry to disagree with so many others here, but I don't think that code generation is a good enough reason by itself to go with an ORM. You can write or find many good DAL templates for code generators that do not have the conceptual or performance overhead that ORM's do.
我很抱歉在这里不同意这么多其他人的观点，但我认为代码生成本身不足以成为使用 ORM 的充分理由。您可以为代码生成器编写或找到许多不错的 DAL 模板，这些模板没有 ORM 那样的概念或性能开销。
Or, if you think that you don't need to know how to write good SQL to use an ORM, again, I disagree. It might be true that from the perspective of writing single queries, relying on an ORM is easier. But, with ORM's it is far too easy to create poor performing routines when developers don't understand how their queries work with the ORM and the SQL they translate into.
或者，如果您认为您不需要知道如何编写好的 SQL 来使用 ORM，我也不同意。从编写单个查询的角度来看，依赖 ORM 可能更容易。但是，使用 ORM 时，如果开发人员不了解他们的查询如何与 ORM 以及它们转换成的 SQL 一起工作，则很容易创建性能不佳的例程。
Having a data layer that works against multiple databases can be a benefit. It's not one that I have had to rely on that often though.
拥有一个适用于多个数据库的数据层可能是一个好处。不过，这不是我必须经常依赖的。
In the end, I have to reiterate that in my experience, if you are not using the more advanced query features of your ORM, there are other options that solve the remaining problems with less learning and fewer CPU cycles.
最后，我必须重申，根据我的经验，如果您没有使用 ORM 更高级的查询功能，还有其他选项可以通过更少的学习和更少的 CPU 周期来解决剩余的问题。
Oh yeah, some developers do find working with ORM's to be fun so ORM's are also good from the keep-your-developers-happy perspective. =)
哦，是的，一些开发人员确实发现使用 ORM 很有趣，所以从让开发人员开心的角度来看，ORM 也很好。=)
回答by Bill Karwin
Speeding development. For example, eliminating repetitive code like mapping query result fields to object members and vice-versa.
加快发展。例如，消除重复代码，例如将查询结果字段映射到对象成员，反之亦然。
回答by Bill Karwin
Supporting OO encapsulation of business rules in your data access layer. You can write (and debug) business rules in your application language of preference, instead of clunky trigger and stored procedure languages.
支持在您的数据访问层中对业务规则进行 OO 封装。您可以使用您喜欢的应用程序语言编写（和调试）业务规则，而不是使用笨重的触发器和存储过程语言。
回答by Bill Karwin
Generating boilerplate code for basic CRUD operations. Some ORM frameworks can inspect database metadata directly, read metadata mapping files, or use declarative class properties.
为基本的 CRUD 操作生成样板代码。一些 ORM 框架可以直接检查数据库元数据、读取元数据映射文件或使用声明性类属性。
回答by Matt Fenelon
You can move to different database software easily because you are developing to an abstraction.
您可以轻松迁移到不同的数据库软件，因为您正在开发一个抽象。
回答by curiousdork
Development happiness, IMO. ORM abstracts away a lot of the bare-metal stuff you have to do in SQL. It keeps your code base simple: fewer source files to manage and schema changes don't require hours of upkeep.
发展幸福，海事组织。ORM 抽象了您必须在 SQL 中执行的许多裸机操作。它使您的代码库保持简单：需要管理的源文件更少，架构更改不需要数小时的维护。
I'm currently using an ORM and it has sped up my development.
我目前正在使用 ORM，它加快了我的开发。
回答by cletus
So that your object model and persistence model match.
以便您的对象模型和持久性模型匹配。
回答by Tim Wardle
To minimise duplication of simple SQL queries.
尽量减少简单 SQL 查询的重复。
回答by Dan McClain
The reason I'm looking into it is to avoid the generated code from VS2005's DAL tools (schema mapping, TableAdapters).
我正在研究它的原因是为了避免从 VS2005 的 DAL 工具（架构映射、TableAdapters）生成代码。
The DAL/BLL i created over a year ago was working fine (for what I had built it for) until someone else started using it to take advantage of some of the generated functions (which I had no idea were there)
我一年多前创建的 DAL/BLL 运行良好（对于我构建它的目的），直到其他人开始使用它来利用一些生成的函数（我不知道在那里）
It looks like it will provide a much more intuitive and cleaner solution than the DAL/BLL solution from http://wwww.asp.net
看起来它会提供比http://wwww.asp.net的 DAL/BLL 解决方案更直观、更简洁的解决方案
I was thinking about created my own SQL Command C# DAL code generator, but the ORM looks like a more elegant solution
我正在考虑创建自己的 SQL 命令 C# DAL 代码生成器，但 ORM 看起来像一个更优雅的解决方案
