你为什么要使用ORM？

Question

如果您要激励为什么要将ORM用于管理/客户的“专业人士”，原因是什么？

尝试并保留每个答案的一个理由，以便我们可以看到被投票的内容是最佳理由

Answer 1

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

我想到的一种查询是多态查询。简单的ORM查询可能会选择数据库中的所有形状。你得到了一系列形状。但根据其鉴别器，每个实例都是正方形，圆形或矩形。

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

我很抱歉在这里不同意这么多人，但我认为代码生成本身并不足以成为ORM的理由。您可以为代码生成器编写或找到许多优秀的DAL模板，这些代码生成器没有ORM所做的概念或性能开销。

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

拥有一个适用于多个数据库的数据层可能是一个好处。不过，我不得不依赖它。

最后，我必须重申，根据我的经验，如果您没有使用ORM的更高级查询功能，还有其他选项可以解决剩余问题，减少学习和减少CPU周期。

哦，是的，一些开发人员确实发现与ORM一起工作很有趣，所以从保持开发人员的快乐角度来看，ORM也很好。 =）

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

为基本CRUD操作生成样板代码。一些ORM框架可以直接检查数据库元数据，读取元数据映射文件或使用声明性类属性。

Answer 6

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

Answer 7

这样你的对象模型和持久性模型就匹配了。

Answer 8

发展幸福，国际海事组织。 ORM抽象了你在SQL中必须做的许多裸机。它使您的代码库保持简单：管理的源文件更少，架构更改不需要数小时的维护。

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

Answer 9

尽量减少简单SQL查询的重复。

Answer 10

我正在调查的原因是避免使用VS2005的DAL工具生成的代码（架构映射，TableAdapters）。

我在一年前创建的DAL / BLL工作正常（我为之建立的），直到其他人开始使用它来利用一些生成的函数（我不知道在那里）< / p>

看起来它会提供比http://wwww.asp.net

的DAL / BLL解决方案更直观，更清晰的解决方案

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

Answer 11

查询的编译和测试。

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

编译查询有助于帮助开发人员更快地发现错误。对？对。这种编译是可能的，因为开发人员现在使用他们的业务对象或模型在代码中编写查询，而不仅仅是SQL或SQL语句的字符串。

如果在.NET中使用正确的数据访问模式，则可以轻松地在内存集合中对查询逻辑进行单元测试。这样可以加快测试的执行速度，因为您无需访问数据库，在数据库中设置数据，甚至无法启动完整的数据上下文。[编辑]这不像我认为的那样真实在内存中进行测试可以提供difficult challenges来克服。但我仍然发现这些集成测试比前几年更容易编写。[/ EDIT]

今天这个问题肯定比几年前提出这个问题更有意义，但这可能只是我的经验所在的Visual Studio和实体框架的情况。如果可能，请插入您自己的环境。

Answer 12

抽象sql离开95％的时间，所以不是团队中的每个人都需要知道如何编写超高效的数据库特定查询。

Answer 13

我认为这里有很多好处（可移植性，易于开发/维护，专注于OO业务建模等），但在试图说服您的客户或管理层时，这一切都归结为多少您将使用ORM 节省的资金。

对典型任务（或者甚至是可能会出现的大型项目）进行一些估算，你会（希望！）获得一些难以忽视的切换参数。

Answer 14

使用代码smith模板

.net层

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

为什么编写可以生成的东西。

Answer 15

说服他们在进行更改时会节省多少时间/金钱，而且您不必重写SQL，因为ORM工具会为您执行此操作

Answer 16

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

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

我理解这个问题是通用的。但移动应用程序也属于通用伞。