为什么要使用 ORM？

减少简单 SQL 查询的重复。

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

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

使您的对象模型和持久性模型匹配。

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

. net 层使用代码 Smith 模板

Http://nettiers.com/default.aspx

为什么要编写可以生成的代码。

我研究它的原因是为了避免从 VS2005的 DAL 工具(模式映射，TableAdapters)生成代码。

一年多以前我创建的 DAL/BLL 工作得很好(对于我构建它的目的而言) ，直到有人开始使用它来利用一些生成的函数(我不知道那里有这些函数)

看起来它将提供一个比 http://wwww.asp.net的 DAL/BLL 解决方案更直观、更清晰的解决方案

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

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

说服他们当变更发生时你将节省多少时间/金钱，而且你不必重写你的 SQL，因为 ORM 工具会为你做这些

您可以很容易地转移到不同的数据库软件，因为您正在开发一个抽象。

95% 的时间都在抽象 sql，因此团队中并非每个人都需要知道如何编写超高效的特定于数据库的查询。

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

我考虑的一种查询类型是多态查询。一个简单的 ORM 查询可以选择数据库中的所有形状。你会得到一系列的图形。但是每个实例都是一个正方形、圆形或矩形，根据它的判别器。

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

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

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

拥有一个针对多个数据库的数据层可能是一个好处。不过我并不经常依赖它。

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

哦，是的，一些开发人员确实发现与 ORM 一起工作很有趣，所以从让开发人员高兴的角度来看，ORM 也很好。=)

我认为这里有很多优点(可移植性、易于开发/维护、专注于面向对象业务建模等) ，但是当试图说服客户或管理层时，这些都归结为 使用 ORM 可以节省多少钱。

对典型的任务(或者可能出现的更大的项目)做一些估计，你就会(希望如此!)得到一些难以忽视的关于转换的论据。

发展快乐，我的天。ORM 抽象了许多在 SQL 中必须执行的裸金属操作。它使您的代码基础保持简单: 要管理的源文件更少，模式更改不需要数小时的维护。

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

查询的编译和测试。

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

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

中使用正确的数据访问模式。NET 很容易在内存集合中对查询逻辑进行单元测试。这样可以加速测试的执行，因为您不需要访问数据库、在数据库中设置数据，甚至不需要旋转完整的数据上下文。[编辑]这并不像我想象的那样正确，因为内存中的单元测试可以提供 困难的挑战来克服。但是我仍然发现这些集成测试比前几年更容易编写。[/编辑]

与几年前提出这个问题时相比，今天的情况显然更为相关，但这可能只适用于我的经验所在的 Visual Studio 和 Entity Framework。如果可能，插入您自己的环境。

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

我是一个 Android 开发者，正如你所知道的，移动应用程序的规模通常不是很大，所以这种将纯模型和受模型影响的模型隔离开来的额外努力似乎并不值得。

我明白这个问题是一般性的，但是移动应用程序也包含在一般性的保护伞中。