为什么要使用ORM？
如果你要激励你为什么要使用ORM来pipe理/客户的“优点”，原因是什么？
尝试并保持每个答案的一个原因，以便我们可以看到被投票的最佳理由
使数据访问更加抽象和便携。 ORM实现类知道如何编写供应商特定的SQL，所以你不必这样做。
使用ORM的最重要原因是，您可以拥有一个丰富的，面向对象的业务模型，并且仍然能够存储它并快速地针对关系数据库编写有效的查询。 从我的观点来看，与其他生成的DAL相比，一个好的ORM给你带来的任何真正的优势，除了你可以编写的高级查询之外。
我正在考虑的一种types的查询是多态查询。 一个简单的ORM查询可能会select数据库中的所有形状。 你得到了一个形状的集合。 但根据其鉴别器，每个实例都是正方形，圆形或矩形。
另一种types的查询将是在单个数据库调用中热切地提取对象和一个或多个相关对象或集合的查询。 例如，每个形状对象都返回其顶点和侧边集合填充。
我很抱歉不同意这里的其他许多人，但我认为代码生成本身并不是一个足够好的理由去使用ORM。 您可以为代码生成器编写或查找许多不错的DAL模板，这些代码生成器不具有ORM所做的概念或性能开销。
或者，如果你认为你不需要知道如何编写好的SQL来使用ORM，我不同意。 从编写单个查询的angular度来看，依靠ORM可能更容易。 但是，对于ORM来说，当开发人员不了解他们的查询如何处理ORM和它们转换的SQL时，创buildperformance不佳的例程就太容易了。
有一个对多个数据库有效的数据层可以是一个好处。 这不是我不得不经常依赖的那个。
最后，我必须重申，根据我的经验，如果您没有使用ORM的更高级的查询function，还有其他选项可以解决剩余问题，减less学习时间，减lessCPU周期。
哦，是的，有些开发人员会发现ORM的工作非常有趣，所以ORM的开发人员也很高兴。 =）
加快发展。 例如，消除重复的代码，如将查询结果字段映射到对象成员，反之亦然。
支持数据访问层中业务规则的OO封装。 您可以使用您喜欢的应用程序语言编写（和debugging）业务规则，而不是笨重的触发器和存储过程语言。
为基本的CRUD操作生成样板代码。 一些ORM框架可以直接检查数据库元数据，读取元数据映射文件或使用声明性类属性。
这样你的对象模型和持久性模型相匹配。
您可以轻松地移动到不同的数据库软件，因为您正在发展为一个抽象。
我正在研究的原因是避免从VS2005的DAL工具（模式映射，TableAdapter）生成的代码。
我在一年前创build的DAL / BLL工作正常（为我所build立的），直到有人开始使用它来利用一些生成的函数（我不知道在那里）
看起来它将提供比http://wwww.asp.net的DAL / BLL解决scheme更直观，更清洁的解决scheme
我想创build我自己的SQL命令C＃DAL代码生成器，但ORM看起来像一个更优雅的解决scheme
最小化简单SQL查询的重复。
编译和testing查询。
随着ORM工具的改进，通过编译时错误和testing更容易确定查询的正确性。
编译查询有助于帮助开发人员更快地发现错误。 对？ 对。 由于开发人员现在正在使用其业务对象或模型在代码中编写查询，而不仅仅是SQL或SQL类似语句的string，因此编译成为可能。
如果在.NET中使用正确的数据访问模式，则可以很容易地将您的查询逻辑与内存集合进行unit testing。 这加快了testing的执行速度，因为您不需要访问数据库，在数据库中设置数据，甚至可以创build一个完整的数据上下文。[编辑]这不像我以为它是单位在记忆中进行testing可能会遇到困难的挑战 。 但是我仍然发现这些集成testing比以往更容易编写。[/编辑]
今天这个问题肯定比几年前问的时候更有意义，但是对于我的经验所在的Visual Studio和Entity Framework来说，情况可能是这样。 如果可能的话，插入你自己的环境。
发展幸福，海事组织。 ORM将SQL中的大量裸机内容抽象出来。 它使您的代码库变得简单：pipe理更less的源文件和更改模式不需要几个小时的维护。
我正在使用一个ORM，它加快了我的发展。
说服他们，当变化进来时你将节省多less时间/金钱，你不必重写你的SQL，因为ORM工具将为你做
把95％的时间抽象出来，所以并不是每个人都需要知道如何编写超高效的数据库特定的查询。
我认为这里有很多优点（可移植性，易于开发/维护，专注于面向对象的业务build模等），但是当试图说服你的客户或pipe理人员时，这一切归结为你将节省多less钱一个ORM 。
对典型的任务（甚至更大的项目可能会出现）做一些估计，你会（希望！）得到一些很难忽略的转换的论点。
我认为有一个缺点就是ORM在你的POJO中需要更新一些。 主要涉及到模式，关系和查询。 所以假设你不想在模型对象中进行更改，可能是因为它在项目或黑白客户端和服务器上共享。 所以在这种情况下，你需要把它分成两个层次，这需要额外的努力。
我是一名android开发人员，而且您知道移动应用程序的体积通常不是很大，所以这种将纯模型和受orm影响的模型分开的额外工作似乎并不值得。
我明白这个问题是通用的。 但移动应用程序也是通用的保护伞。
