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

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

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

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

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

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

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

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

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

我开发的一个应用是用python写的IRC机器人。它使用的模块在单独的线程中运行，但我还没有找到一种方法来处理使用sqlite时的线程。不过，这可能是一个单独的问题。

我真的应该把题目和问题都改写一下。我从来没有在任何语言中使用过DAL。

ORM不仅仅是可移植性(就这一点而言，即使使用ORM也很难实现可移植性)。当ORM工具将您从编写模板SQL查询(通过PK或谓词、插入、更新和删除进行选择)中解放出来，并让您专注于问题域时，它基本上为您提供了持久存储之上的抽象层。

ORMs have some nice features. They can handle much of the dog-work of copying database columns to object fields. They usually handle converting the language's date and time types to the appropriate database type. They generally handle one-to-many relationships pretty elegantly as well by instantiating nested objects. I've found if you design your database with the strengths and weaknesses of the ORM in mind, it saves a lot of work in getting data in and out of the database. (You'll want to know how it handles polymorphism and many-to-many relationships if you need to map those. It's these two domains that provide most of the 'impedance mismatch' that makes some call ORM the 'vietnam of computer science'.)

对于事务性应用程序，即您发出请求，获取一些对象，遍历它们以获得一些数据并在Web页面上呈现，性能损失很小，并且在许多情况下ORM可以更快，因为它将缓存以前见过的对象，否则将多次查询数据库。

对于报告量大的应用程序，或者每个请求都要处理大量的数据库行，ORM税要重得多，它们所做的缓存变成了一个巨大的、无用的内存占用负担。在这种情况下，可以使用简单的SQL映射(LinQ或iBatis)或在瘦DAL中手工编写SQL查询。

我发现，对于任何大型应用程序，您都会发现自己同时使用这两种方法。(ORM用于直接的CRUD, SQL/thin DAL用于报告)。