Java Persistence API 中带注释的命名查询是否真的非常有用？

核心提示： 在上面的代码中，即使使用注释、单独的 XML 文件或不使用任何内容（必须映射每个字段）来映射 Order 或 Item 类，Java Persistence API 中带注释的命名查询是否真的非常有用？(5)，我仍能够使用此 XML 覆盖它，当需要 SQL 的灵活性时，但是我担心在 ORM 范围

在上面的代码中，即使使用注释、单独的 XML 文件或不使用任何内容（必须映射每个字段）来映射 Order 或 Item 类，我仍能够使用此 XML 覆盖它。当需要 SQL 的灵活性时，通过 JPA 本机查询，可以将 JPA 用作 JDBC 框架（类似于 IBatis）。（在我的博客和以后的文章中，我将说明此示例。）

更大的问题

我选择使用命名查询来说明一个更大的问题。将对象关系域映射 (ORM) 创建为支持抽象的应用程序，以便使用面向对象的技术来满足他们的域。ORM 将抽象出数据库。带注释的映射不能满足此类抽象的要求。尽管此类抽象并不是一直需要，但它适合于许多情形。

JPA 规范本身就很有吸引力。JPA 使用外部 XML 映射文件支持映射您的域模型。不过，示例和文档中几乎没有这方面的说明。规范委员会有很大责任，因为他们仅提供带注释的实例，这暗示注释是 JPA 的首选机制。但是，他们有正当理由建议映射文件可能是首选机制：

客户端应用程序可以共享源代码，因此，它们完全了解底层数据库的知识。甚至可以尝试在客户端计算机上执行 SQL 操作。

如果希望将对象映射到多个数据库，又该如何操作呢？尽管可以使用 XML 覆盖注释，但是如果对象有几个映射，那么我可能不会喜欢任何一个。在 SOA 环境中，我可以跨 ESB 发送对象，每个服务都需要有指向自已环境的映射。

如果数据库发生更改——即使使用 XML 覆盖映射——则源代码无法在语义上映射底层映射。任何人都不知道 XML 覆盖会出现错误和假设。在正常部署过程中，信息（如数据库架构名称）会不断变化，而在源中具有此信息无疑会阻碍部署。

对于开发人员来说，注释的确使某些事情变得非常容易，但这又以丧失简洁性为代价。我认为全球的 JPA 编写者通常在进行一些不利于社区的活动，因为不能记录使用 JPA 的 XML 映射样式的清晰示例。

结束语

命名查询只是注释如何被过度使用的一个示例。注释有许多用途，但是我担心在 ORM 范围内滥用了它们。在我的网络日志中，我将花费一些时间来说明使用 JPA 的 XML 映射样式的示例。