Xml配置与基于注释的配置

Question

在我最近一直在研究的几个大型项目中，选择其中一个（XML或注释）似乎变得越来越重要。随着项目的增长，一致性对可维护性非常重要。

我的问题是，人们喜欢什么。你更喜欢基于XML还是Annotation？或两者？每个人都在谈论XML配置地狱，以及注释是如何回答的，那么Annotation配置怎么样？

Answer 1

注解有它们的用途，但它们不是杀死XML配置的一个银色子弹。我建议混合两个！例如，如果使用Spring，将XML用于应用程序的依赖注入部分是完全直观的。这使代码的依赖性远离将要使用它的代码，相反，在代码中使用某种注释需要依赖性使代码意识到这种自动配置。

但是，不是使用XML进行事务管理，而是将方法标记为具有注释的事务处理，这是非常有意义的，因为这是程序员可能希望知道的信息。但是一个接口将被注入为一个SubtypeY而不是SubtypeX，因为如果现在你想注入SubtypeX，你必须改变你的代码，而你之前有一个接口合约，所以使用XML，您只需更改XML映射，这样做相当快速且轻松。

我还没有使用过JPA注解，所以我不知道它们有多好，但我会争辩说，将bean映射到XML中的数据库也是好事，因为对象不应该关心哪里它的信息来自于它，它应该关心它可以用它的信息做些什么。但是，如果你喜欢JPA（我对此没有任何期望），无论如何，请去尝试。

一般来说： 如果注释提供了功能并作为注释本身，并且不会将代码绑定到某个特定过程以便在没有此注释的情况下正常运行，那么请进行注释。例如，标记为事务性的事务性方法不会中止其操作逻辑，并且也可以作为良好的代码级别评论。否则，这个信息最好用XML表示，因为尽管它最终会影响代码的运行方式，但它不会改变代码的主要功能，因此不属于源文件。

Answer 2

我可能是错的，但我认为Annotations（如Java的@Tag和C＃的[Attribute]）是编译时选项，XML是运行时选项。对我来说，这不是等同的，有不同的优点和缺点。

Answer 3

这是经典的“配置与公约”问题。个人品味在大多数情况下决定了答案。不过，我个人比较喜欢配置（即基于XML）和Convention。 IMO IDE足够强大，足以克服人们经常与建筑物相关联的一些XML地狱，并维护基于XML的方法。最后，我发现配置的好处（比如构建实用程序来构建，维护和部署XML配置文件）远远超过了Convention。

Answer 4

这取决于你想要配置什么，因为有一些选项不能用配置来配置。如果我们看到它从注释的一面：

• 加：注释不太对讲机
• 减：注解是不可见

这是给你更重要的是...

一般来说，我会建议选择一种方式，并在产品的一些封闭部分使用它...

（有一些例外：例如，如果您选择基于XML的配置离子，可以使用@Autowire注释。它的混合，但是这一个既有助于可读性和可维护性）

Answer 5

我经常思考的注解作为某种指标是什么一类是能够或如何与他人互动。在另一方面，以我

Spring XML配置就是这样，配置

例如，关于代理的IP和端口信息，被definetly进入一个XML文件，它是运行时配置。

使用@Autowire，@Element来指示框架如何处理该类是很好的使用注释。

将URL放入@Webservice注释中是不好的样式。

但这只是我的看法。 交互和配置之间的界限并不总是很清楚。

Answer 6

我也认为混合是最好的事情，但它也取决于配置参数的类型。 我正在使用Spring的Seam项目，我通常将其部署到不同的开发和测试服务器。所以，我已经分手：

• 服务器的具体配置（像绝对路径上的服务器资源）：Spring的XML文件
• 注入豆类其他豆类的成员（或重复使用在许多豆Spring的XML定义的值）：注释

关键的区别是，您不必重新编译所有更改服务器特定配置的代码，只需编辑xml文件即可。 还有一个优势是，一些配置更改可以由不了解所有代码的团队成员完成。

Answer 7

我使用两者。大多数情况下是XML，但是当我有一堆从一个普通类继承而来的具有公共属性的bean时，我在超类中使用了这些注释，所以我不必为每个bean设置相同的属性。因为我是一个控制怪胎，我使用@Resource（name =“referencedBean”）而不是自动装配的东西（并且如果我需要与原始的引用Bean相同的类的另一个bean，则可以节省很多麻烦） 。

Answer 8

使用仅注解方法的一个重要部分是“bean名称”的概念或多或少地消失（变得无关紧要）。

Spring中的“bean名称”形成了对实现类的更多抽象级别。使用XML bean是相对于它们的bean名称进行定义和引用的。通过注释他们被他们的类/接口引用。（虽然豆名存在，你不需要知道它）

我坚信，摆脱多余的抽象简化了系统，提高了生产力。对于大项目我认为通过摆脱XML的收益可以是相当大的。

Answer 9

我几年来一直在使用Spring并且所需的XML数量确实变得单调乏味。新的XML模式和Spring 2.5的注解支持之间我通常做这些事：

1. 使用“组件扫描”于使用@Repository，@Service或@Component自动加载类。我通常给每个bean一个名字，然后用@Resource将它们连接在一起。我发现这个管道并不经常改变，所以注释是有道理的。

2. 对所有AOP使用“aop”命名空间。这真的很好。我仍将它用于交易，因为将@Transactional放在整个地方都是一种拖累。您可以为任何服务或存储库上的方法创建命名切入点，并快速应用这些建议。

3. 我使用LocalContainerEntityManagerFactoryBean和HibernateJpaVendorAdapter配置Hibernate。这让Hibernate可以轻松自动发现类路径上的@Entity类。然后我使用参考LCEMFB的“factory-bean”和“factory-method”创建一个名为SessionFactory的bean。

Answer 10

我认为通过基于XML的方法，可见性是一个巨大的胜利。考虑到用于导航XML文档的各种工具（即Visual Studio + ReSharper的文件结构窗口），我发现XML并不是那么糟糕。

您当然可以采取混合的方法，但这对我来说似乎很危险，因为这可能会使项目上的新开发人员很难找出配置或映射不同对象的位置。

我不知道;到底XMLHell对我来说似乎并不那么糟糕。

Answer 11

这里存在一个更广泛的问题，即外部元素与内部元数据的问题。如果您的对象模型只能以一种方式持续存在，那么内联元数据（即注释）更加紧凑和易读。

但是，如果您的对象模型在不同的应用程序中被重复使用，以至于每个应用程序都希望以不同的方式持久保存模型，那么将元数据（即XML描述符）外部化就变得更合适。

没有一个更好，所以都支持，虽然注释更时尚。因此，像JPA这样的新发型框架倾向于更加强调它们。像本地Hibernate这样的更成熟的API提供了这两种API，因为众所周知，没有一个是足够的。

Answer 12

在DI容器的范围内，我认为基于注释的DI是滥用Java注释的使用。通过这样说，我不建议在您的项目中广泛使用它。如果你的项目确实需要DI容器的强大功能，我会推荐使用基于Xml的Spring IoC配置选项。

如果仅仅是为了单元测试的缘故，开发人员应该在编码中应用依赖注入模式，并利用模拟工具（如EasyMock或JMock）的优势来规避依赖关系。

您应该尽量避免在错误的环境中使用DI容器。

Answer 13

还有其他方面可以比较重构和其他代码更改。当使用XML时，需要花费很多精力来进行重构，因为您必须处理所有XML内容。但使用注释很容易。

我的首选方式是基于Java的配置，没有（或最小的）注释。 http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Answer 14

有从我的经验一些优点和注释配置的缺点：

• 当，因为它是做一次，通常不会改变经常我宁愿坚持注释配置涉及到JPA的配置。可能会有人担心可能会看到更大的配置图 - 在这种情况下，我使用MSQLWorkbench图。
• Xml配置非常适合获得更大的应用程序图片，但直到运行时才会发现一些错误。在这种情况下，Spring的注释听起来更好，因为它可以让你看到更大的图像，并且允许在编译时验证配置。
• 至于Spring配置，我更喜欢将两种方法结合使用：使用@Configuration注释与服务和查询接口和XML配置dataSource和弹簧配置的东西，如上下文：component-scan base-package =“...”
• 但是，当涉及到流配置（Spring Web Flow或Lexaden Web Flow）时，xml配置位会对java注释进行处理，因为查看整个业务流程的全景图非常重要。使用注释方法实现它听起来很麻烦。

我更喜欢结合两种方法 - java注释和最小化配置地狱的基本xml。

Answer 15

总是要链接到特定Java组件（类，方法或字段）的配置信息是一个很好的候选项，可以用注释表示。在这种情况下，当配置是代码目的的核心时，注释特别适用。由于注释的限制，每个组件只能有一个配置时也是最好的。如果您需要处理多种配置，尤其是那些对包含注释的Java类以外的任何条件有条件的配置，则注释可能会产生比解决问题更多的问题。最后，无需重新编译Java源代码即可修改注释，因此在运行时需要重新配置的任何内容都不能使用注释。

请参考以下链接。它们也可能有用。

1. Annotations vs XML, advantages and disadvantages
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Answer 16

对于Spring框架，我喜欢的是能够使用@Component注释和设置“组件扫描”选项的想法，使Spring能够找到我的Java bean这样我就不必在XML中定义所有的bean，也不必在JavaConfig中定义。例如，对于无状态的单独java bean，只需要连接到其他类（理想地通过接口），这种方法非常有效。一般来说，对于Spring bean，我大部分已经远离Spring XML DSL来定义bean，并且现在更倾向于使用JavaConfig和Spring Annotations，因为您可以在编译时检查配置和重构支持，使用Spring XML配置。在某些极少数情况下，我发现JavaConfig/Annotations无法执行使用XML配置的功能。

对于Hibernate ORM（尚未使用JPA），我仍然更喜欢XML映射文件，因为域模型类中的注释在某种程度上违反了The Clean Architecture这是我在过去几年中采用的分层体系结构样式。发生违规是因为它要求核心层依赖于与持久性相关的事物，例如Hibernate或JPA库，并且它使得域模型POJOs少一点持久性是无知的。事实上，核心层不应该依赖任何其他基础设施。然而，如果清洁架构不是您的“一杯茶”，那么我可以看到在分离的XML映射文件中使用域模型类中的Hibernate/JPA注释肯定具有优势（例如便利性和可维护性）。