# Hiberate 注解与映射 – 优缺点 > 原文： [https://howtodoinjava.com/hibernate/pros-and-cons-of-hibernate-annotations-vs-mappings/](https://howtodoinjava.com/hibernate/pros-and-cons-of-hibernate-annotations-vs-mappings/) 您可能知道，在内联注解之前，创建 Hiberate 映射的唯一方法是通过 XML 文件。 尽管来自 Hibernate 和第三方项目的各种工具允许部分或全部映射从 Java 源代码自动生成。 如今，注解是定义映射的最新方法，但并不是自动的最佳方法。 让我们先讨论 Hiberate（或我应该说 JPA）注解的缺点和好处，然后再讨论何时应用它们。 ## Hiberate 注解的缺点 让我们一一列出所有可能的缺点。 * 如果要从 Hibernate 2 环境升级或使用现有的 Hibernate 3 环境，则您将已经具有基于 XML 的映射文件来支持您的代码库。 在所有其他条件都相同的情况下，您不希望仅出于注解目的而使用注解重新表达这些映射。 您将要坚持使用映射，因为它们仍然可以正常运行并且运作良好。 * 因此，如果您要从旧版环境迁移，则可能不希望更改现有的 POJO 源代码，换句话说，您将不会注入可能存在错误的已知良好代码。 * 如果您没有 POJO 的源代码（因为它是由自动化工具或类似的代码（例如旧版代码）生成的），则与反编译类文件以获得 Java 源代码相比，您可能更喜欢使用基于 XML 的外部映射 更改代码。 * 通过将映射信息保留为外部 XML 文件，可以修改映射信息以反映业务更改或架构更改，而不必强制您重新构建整个应用。 ## Hiberate 注解的优点 考虑了缺点之后，使用注解会有一些强大的好处。 * 首先，也许是最有说服力的是，我们发现基于注解的映射比基于 XML 的替代更加直观，因为它们与相关的属性一起直接出现在源代码中。 大多数编码人员倾向于使用注解，因为必须保持较少的文件同步。 * 部分原因是，注解不如 XML 等效项那么冗长。 让我们看一下比较 ```java import javax.persistence.* ; @Entity public class Sample { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) public Integer id; public String name; } ``` 并将其与等效的映射文件进行比较。 ```java <?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd "> <hibernate-mapping default-access="field"> <class name="Sample"> <id type="int" column="id"> <generator class="native"/> </id> <property name="name" type="string"/> </class> </hibernate-mapping> ``` 后者的一些冗长是 XML 本身的本质（标记名和样板文档类型声明），而某些是由于注解与源代码的紧密集成所致。 * 另一个主要的好处是 Hiberate 使用并支持 JPA2 持久化注解。 如果选择不在代码和注解中使用特定于 Hibernate 的功能，则可以使用支持 JPA2 的其他 ORM 工具将实体部署到环境中。 * 最后，也许是次要的一点，因为注解被直接编译到适当的类文件中，因此丢失或陈旧的映射文件在部署时引起问题的风险较小。 ## 选择使用哪个 通常，更喜欢注解； 注解本身可以在 JPA 实现中移植，并且众所周知。 工具可以直接从数据库中创建带注解的源代码，因此，即使使用预先存在的模式，同步也没有多少麻烦。 XML 映射既可以采用 Hibernate 的专有格式，也可以采用 JPA 的标准 XML 配置，它们相似但不相同； 如果您以某种方式发现 XML 是首选的配置格式，则最好使用行业标准 JPA 配置中的 XML 格式。 让我知道您的想法，您更喜欢哪种，为什么？ **祝您学习愉快！**