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

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

作为一个经常使用JPA (Java Persistence API，基本上是Java/J2EE/EJB的标准化ORM API)(包括Hibernate、EclipseLink、Toplink、OpenJPA等)的人，我将分享一些我的观察结果。

ORMs are not fast. They can be adequate and most of the time adequate is OK but in a high-volume low-latency environment they're a no-no; In general purpose programming languages like Java and C# you need an awful lot of magic to make them work (eg load-time weaving in Java, instrumentation, etc); When using an ORM, rather than getting further from SQL (which seems to be the intent), you'll be amazed how much time you spend tweaking XML and/or annotations/attributes to get your ORM to generate performant SQL; For complex queries, there really is no substitute. Like in JPA there are some queries that simply aren't possible that are in raw SQL and when you have to use raw SQL in JPA it's not pretty (C#/.Net at least has dynamic types--var--which is a lot nicer than an Object array); There are an awful lot of "gotchas" when using ORMs. This includes unintended or unexpected behavior, the fact that you have to build in the capability to do SQL updates to your database (by using refresh() in JPA or similar methods because JPA by default caches everything so it won't catch a direct database update--running direct SQL updates is a common production support activity); The object-relational mismatch is always going to cause problems. With any such problem there is a tradeoff between complexity and completeness of the abstraction. At times I felt JPA went too far and hit a real law of diminishing returns where the complexity hit wasn't justified by the abstraction.

还有一个问题需要更多的解释。

Web应用程序的传统模型是有一个持久层和一个表示层(中间可能有一个服务或其他层，但这是本文中重要的两个层)。orm强制从持久层到表示层(即实体)使用刚性视图。

对更原始SQL方法的批评之一是，您最终会得到所有这些仅由一个查询使用的vo(值对象)或dto(数据传输对象)。这被吹捧为orm的一个优势，因为你摆脱了这一点。

问题是，这些问题不会随着orm而消失，它们只会上升到表示层。不为查询创建VOs/ dto，而是创建自定义表示对象，通常为每个视图创建一个。这怎么更好呢?恕我直言，它不是。

我已经用ORM或SQL写过了:我们做到了吗?

最近我选择的持久化技术(在Java中)是ibatis。它是一个非常薄的SQL包装器，可以完成JPA所能做的90%以上的工作(它甚至可以进行惰性加载关系，尽管它没有良好的文档)，但开销要小得多(就复杂性和实际代码而言)。

这是在去年我编写的GWT应用程序中出现的。在服务实现中，从EclipseLink到表示对象的大量转换。如果我们使用ibatis，那么用ibatis创建适当的对象，然后在堆栈中上下传递它们就会简单得多。一些纯粹主义者可能会认为这是坏的™。也许是这样(理论上)，但我告诉你:它会带来更简单的代码、更简单的堆栈和更高的生产力。

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

例如:

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

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

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

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

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

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

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

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