我知道这个问题很老了，但我想我应该在这里发布一个答案，以防有人像我一样遇到这个问题。orm已经走过了很长的路。其中一些实际上为您提供了两全其美的服务:提高开发效率并保持性能。

看看SQL Data (http://sqldata.codeplex.com)。它是c#的一个轻量级ORM，涵盖了所有基础。

供参考，我是SQL数据的作者。

使我的ORM使用真正成功的关键是代码生成。就代码性能而言，我同意ORM路由不是最快的。但是，当您拥有一个中型到大型的团队时，DB正在迅速变化，从DB中重新生成类和映射作为构建过程的一部分的能力是值得注意的，特别是当您使用CI时。所以你的代码可能不是最快的，但你的代码会-我知道我在大多数项目中会采用哪种。

我的建议是在模式仍处于流动状态时使用ORM进行开发，使用分析来发现瓶颈，然后使用原始Sql优化那些需要它的区域。

另一个想法是，如果使用得当，Hibernate内建的缓存通常可以大大提高性能。不再需要返回DB读取引用数据。

在现代软件开发场景中，是否使用框架是非常常见的难题。

重要的是要理解每个框架或方法都有其优点和缺点——例如，根据我们的经验，我们发现ORM在处理事务时很有用，即插入/更新/删除操作——但当涉及到获取具有复杂结果的数据时，评估ORM工具的性能和有效性就变得重要了。

同样重要的是要理解，选择一个框架或方法并在其中实现所有内容并不是强制性的。我们的意思是，我们可以混合使用ORM和本地查询语言。许多ORM框架在本地SQL中为插件提供扩展点。我们应该尽量不要过度使用一个框架或方法。我们可以结合某些框架或方法，得出适当的解决方案。

当涉及到高并发性的插入、更新、删除和版本控制时，可以使用ORM，还可以使用Native SQL生成报告和长清单

使用像SQL一样工作的ORM，但提供编译时检查和类型安全。比如我最喜欢的:数据知识对象(披露:是我写的)

例如:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

完全流。易于设置(不需要定义映射-读取现有模式)。支持连接、事务、内部查询、聚合等。几乎可以用SQL做任何事情。从庞大的数据集(金融时间序列)一直到琐碎的数据集(Android)，这一点都得到了证明。

我想和大家一起回答:“我们有一个中间立场!”

对于应用程序程序员来说，SQL是您可能想要控制的东西和您几乎肯定不想费心控制的东西的混合体。

我一直想要的是一个层(称之为DAL、ORM或microorm，我不介意哪个)，它将负责完全可预测的决策(如何拼写SQL关键字，括号放在哪里，何时创建列别名，为一个包含两个浮点数和一个int的类创建哪些列……)，同时让我负责SQL的高级方面，即如何安排join、服务器端计算、DISTINCTs、GROUP by、标量子查询等。

所以我写了一些这样的东西:http://quince-lib.com/

这是针对c++的:我不知道这是否是你正在使用的语言，但同样的，看看这个“中间地带”的样子可能会很有趣。

没有“一刀切”的解决方案，对于“我是否应该使用an或/m”这个问题也是如此。”。

我会说:如果你必须写一个非常“数据”的应用程序/工具，没有太多的其他逻辑，那么我会使用纯SQL，因为SQL是这类应用程序的领域特定语言。

另一方面，如果我要编写一个包含大量“领域”逻辑的业务/企业应用程序，那么我将编写一个富类模型，它可以在代码中表达这个领域。在这种情况下，OR/M映射器可能会非常有用，因为它可以从您手中省去大量管道代码。