我已经使用 Hibernate 几年了,但只将它与注释一起使用,并在我的代码中设置连接参数。
我是否因为不使用 XML 文件而“遗漏了一些东西”?是否有仅在 XML 中可用的重要功能?是否存在使用 XML 有意义的情况或模式?
我已经使用 Hibernate 几年了,但只将它与注释一起使用,并在我的代码中设置连接参数。
我是否因为不使用 XML 文件而“遗漏了一些东西”?是否有仅在 XML 中可用的重要功能?是否存在使用 XML 有意义的情况或模式?
我认为可以肯定地说你没有错过任何东西。
如果 XML 中有任何不能在属性中表示的功能(我相信有一些罕见的情况),那么您仍然可以选择使用 [RawXml] 并将 XML 写入属性中。因此,您不可能错过任何功能。
如果您的团队中有足够多的程序员只是喜欢管理单独的文件,或者如果确实需要即时编辑 xml 映射,那么使用 XML 可能是有意义的。对于非常复杂的映射,XML 映射文件可能更容易操作,并且它们可以包含有用的信息(关于获取策略的评论等)。
还有体系结构的问题,有些人认为将映射分离到 XML 文件中可以更好地分离业务相关代码和关于如何持久化的指令。
注释是快速配置 Hibernate 的好方法。但是像 Hibernate 这样的 OR 映射器的关键特性之一是您可以让您的域模型“不知道持久性”,您的对象不需要知道它们在何处以及如何持久化。有些人可能会争辩说,使用注释会破坏这一点。在持久性只是众多问题之一的情况下,将事情分开是有意义的。
另一个原因可能是域对象在不同情况下的持久化方式不同,您可以让一个应用程序使用多个数据库,甚至多个应用程序使用相同的域模型。
Hibernate 不使用 EJB3/JPA 标准注解吗?如果是这样,我至少可以想到一个使用 XML 的理由:那些注解不具备 Hibernate 的所有功能。
示例:Hibernate 可以为 ID 定义“本机”类型。这将在 MySQL 上创建一个自动增量字段,在 Oracle 上创建一个序列。没有办法使用在这两种情况下都有效的 JPA 注释来做到这一点。
此外,XML 是可插入的。注释不是。如果您运送到多个数据库平台并且每个平台都有不同的配置,这可能对您很重要。
XML 已经失去了许多开发人员的青睐,仅出于这个原因,我认为很多人喜欢注释。问题是,无论如何您都有 XML(以 persistence.xml 文件的形式,可能还有其他形式)。这有点像一个六个,另一个六个。
在注释中几乎没有什么是您不能在 XML 中做的。我什至想不出任何atm。您可以尝试遵循 JPA,但我发现 JPA API 非常有限。不过,这只是意味着您使用非标准的 Hibernate 特定注释。
有几条评论指出休眠注释会污染您的域模型,但无论如何这些都与您的数据库布局紧密耦合。在任何不是数据库驱动的代码中,无论如何您都需要构建一个中间层。事实上,恕我直言,很多网络应用程序应该使用中间值对象,这些对象只复制表示层所需的数据。相反,许多人在视图反模式中使用开放会话。
最后,虽然 xml 配置很灵活,但通常的做法表明,每当我们编辑 xml 文件时,我们几乎总是在编辑 java 源文件。这只是将配置移近对象的另一个论据,即进入注释。
我会提到,我发现注释的唯一缺点是我必须将相关的注释嵌入到我的域模型的类中,因此任何使用域模型的程序都需要访问 API。
但是,由于各种原因,我不直接保留我的域模型,而是有一个类似(但有些不同)的“持久域模型”,它被持久化并且只在服务器中,所以这不是一个大问题。
不想重复已经说过的任何内容,但我使用 XML 样式配置将其与我的代码分开。这主要是根据我的个人喜好完成的,归根结底,这无关紧要:) 你可以用 XML 做的另一件事是让 hbm2java 为你生成代码,我也喜欢这样做,但它又是一个优势; 可能不是。
所以我想说这只是你喜欢什么的问题。
我不知道您是否在配置中包含命名查询,但我倾向于将它们放在 XML 文件中,即使我认为这会增加实体及其查询之间出错的风险。它允许调整查询而无需重新编译整个应用程序。
如果您将实体从业务重用到表示层,使用 XML 代替注释也可以避免 UI 层中的 JPA 依赖,但我不确定该论点是否相关。
我发现的一件事是,与在 XML 中映射它们相比,注释似乎更容易使用 UUID/GUID 列。但话又说回来,我是 Hibernate 的新手。
无法使用注释创建 dabase 对象,您必须使用
cfg.addAuxiliaryDatabaseObject(new SimpleAuxiliaryDatabaseObject(...sql here...))
为了创建一些特殊的 sql 指令。