我用纯SQL表示读取，用ORM表示CUD。

性能是我一直关注的问题，尤其是在web应用程序中，但同时也关注代码的可维护性和可读性。为了解决这些问题，我编写了SqlBuilder。

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用于报告)。

我用纯SQL表示读取，用ORM表示CUD。

性能是我一直关注的问题，尤其是在web应用程序中，但同时也关注代码的可维护性和可读性。为了解决这些问题，我编写了SqlBuilder。

任何值得尊敬的设计都需要对数据库进行一些抽象，以处理阻抗不匹配。但是我认为最简单的第一步(对于大多数情况来说已经足够了)应该是DAL，而不是重量级的ORM。你唯一的选择并不是那些极端的选择。

编辑回复一个要求我描述如何区分DAL和ORM的评论:

DAL是您自己编写的，可能从简单地封装一个表并将其字段映射到属性的类开始。ORM是不需要为从dbms模式的其他属性推断出的抽象机制而编写的代码，主要是pk和fk。(这是您发现自动抽象是否开始出现漏洞的地方。我更喜欢有意地告知他们，但这可能只是我的个人偏好)。

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

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

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

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

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

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

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

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