是否有充分的理由使用XML而不是通过注释配置hibernate？

我一直在使用Hibernate几年，但只使用它注释，并在我的代码中设置连接参数。

我没有使用XML文件“遗漏了什么”？ 是否只有XML可用的重要function？ 是否存在使用XML有意义的情况或模式？

Answer 1

我认为你不会错过任何事情是非常安全的。

如果XML中的任何function无法在属性中表示（我相信有一些罕见的情况），那么您仍然可以选择使用[RawXml]并在属性中编写XML。 所以你不可能错过任何function。

如果您的团队中有足够的程序员而只是喜欢管理单独的文件，或者如果真的需要动态编辑xml映射，那么使用XML可能是有意义的。 对于非常复杂的映射，Xml映射文件可能更容易操作，并且它们可以包含有用的信息（关于获取策略的注释等）。

还存在架构问题，有些人认为将映射分离为XML文件可以更好地区分业务相关代码和有关如何持久化的指令。

Answer 2

注释是快速配置Hibernate的好方法。 但是像Hibernate这样的OR mappers的一个关键特性就是你保持你的域模型“持久性无知”你的对象不需要知道它们在何处以及如何持久存在。 有些人可能会争辩说，使用注释打破了这一点。 在持久性只是众多问题之一的情况下，将事物分开是有意义的。

另一个原因可能是域对象在不同情况下以不同方式持久存在，您可以将一个应用程序使用多个数据库，或者使用相同域模型的更多应用程序。

Answer 3

Hibernate不使用EJB3 / JPA标准注释吗？ 如果是这样，我至少可以想到使用XML的一个原因：那些注释没有Hibernate的所有function。

示例：Hibernate可以为ID定义“本机”类型。 这将在MySQL上创建一个自动增量字段，在Oracle上创建一个序列。 使用JPA注释无法在两种情况下都能正常工作。

此外，XML是可插拔的。 注释不是。 如果您发送到多个数据库平台并为每个数据库平台配置不同的配置，这对您来说很重要。

XML已经失去了许多开发人员的青睐，仅仅因为这个原因，我认为很多人赞成注释。 事实上，无论如何你都有XML（以persistence.xml文件的forms，可能还有其他文件）。 它有点像六个，另外六个。

Answer 4

在XML中注释几乎没有什么是你不能做的。 我甚至无法想到任何东西。 您可以尝试符合JPA，但我发现JPA API非常有限。 不过，这只是意味着你使用非标准的Hibernate特定注释。

有几条评论指出hibernate注释会污染您的域模型，但这些注释与您的数据库布局紧密相关。 在任何非数据库驱动的代码中，无论如何都需要构建一个中间层。 事实上，恕我直言，很多网络应用程序应该使用中间值对象，只复制表示层所需的数据。 相反，许多人在视图反模式中使用open会话。

最后，虽然xml配置很灵活，但通常的做法表明，每当我们编辑xml文件时，我们几乎总是编辑java源文件。 这只是将配置移近对象（即注释）的另一个参数。

Answer 5

我要提到的是，我发现注释的唯一缺点是我必须在我的域模型的类中嵌入相关的注释，因此无论使用域模型的任何程序都需要访问API。

但是，出于各种原因，我没有直接坚持我的域模型，而是有一个类似的（但有些不同）“持久域模型”，它被持久化并且仅在服务器中，所以这不是一个大问题。

Answer 6

不想重复已经说过的任何内容，但是我使用XML样式配置将它与我的代码分开。 这主要是根据我的个人偏好完成的，并且在一天结束时它不重要:)你可以用XML做的另一件事就是让hbm2java为你生成你的代码，我也喜欢这样，但它又是一个优点; 可能不是。

所以我想说这只是你喜欢什么的问题。

Answer 7

我不知道你是否在配置中包含命名查询，但我倾向于将它们放在XML文件中，即使我认为它会增加实体与其查询之间的错误风险。 它允许调整查询而无需重新编译整个应用程序。

如果从业务层到表示层重用实体，使用XML而不是注释也可以避免UI层中的JPA依赖，但我不确定该参数是否相关。

Answer 8

我发现的一件事是，注释似乎更容易使用UUID / GUID列与使用XML映射它们。 但话说回来，我是Hibernate的新手。

Answer 9

• 目前，不可能使用带注释的液体基料。

• 无法使用注释创建数据库对象，您必须使用

  cfg.addAuxiliaryDatabaseObject（new SimpleAuxiliaryDatabaseObject（… sql here …））

为了创建一些特殊的sql指令。