Xml配置与基于注释的配置

在我最近一直在研究的一些大型项目中,选择其中一个(XML或Annotation)似乎变得越来越重要.随着项目的增长,一致性对于可维护性非常重要.

我的问题是,人们更喜欢什么.您更喜欢基于XML还是基于注释？或两者？每个人都在谈论XML配置地狱以及如何将注释作为答案,那么注释配置到底是什么？

注释有其用途,但它们不是杀死XML配置的银弹.我建议混合两个!

例如,如果使用Spring,那么将XML用于应用程序的依赖注入部分是完全直观的.这使得代码的依赖性远离将要使用它的代码,相反,在代码中使用某种类型的注释需要依赖关系使代码知道这种自动配置.

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

我没有使用JPA注释,所以我不知道它们有多好,但我认为将bean映射到XML中的数据库也很好,因为对象不应该关心它的信息来自何处,它应该只关心它可以用它的信息做什么.但是如果你喜欢JPA(我对它没有任何考虑),那么一定要去吧.

通常:如果注释提供了功能并且本身充当注释,并且没有将代码绑定到某个特定进程以便在没有此注释的情况下正常运行,那么请转到注释.例如,标记为事务的事务方法不会终止其操作逻辑,也可以作为良好的代码级注释.否则,此信息可能最好表示为XML,因为尽管它最终会影响代码的运行方式,但它不会更改代码的主要功能,因此不属于源文件.

这里存在一个更广泛的问题,即外部化和内联元数据.如果您的对象模型只是以一种方式持久化,那么内联元数据(即注释)更加紧凑和可读.

但是,如果您的对象模型在不同的应用程序中重用,每个应用程序都希望以不同的方式保持模型,那么外部化元数据(即XML描述符)就变得更合适了.

虽然注释更时尚,但两者都不是更好,所以两者都得到支持.因此,像JPA这样的新型触发框架往往更加强调它们.像本机Hibernate这样的更成熟的API提供了两者,因为众所周知,这两者都不够.

我经常思考的注解作为某种指标的东西一类是能够,或者如何将其与他人互动.

另一方面,Spring XML配置对我来说就是配置

例如,有关代理的ip和端口的信息肯定会进入XML文件,它是运行时配置.

使用@Autowire,@Element表示框架如何处理类是很好地使用注释.

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

但这只是我的意见.交互和配置之间的界限并不总是很清楚.

我已经使用Spring几年了,所需的XML量肯定变得乏味.在Spring 2.5中的新XML模式和注释支持之间,我通常会做以下事情:

使用"component-scan"自动加载使用@ Repository,@ Service或@Component的类.我通常给每个bean命名,然后使用@Resource将它们连接在一起.我发现这个管道并没有经常改变,因此注释是有意义的.

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

我使用LocalContainerEntityManagerFactoryBean和HibernateJpaVendorAdapter来配置Hibernate.这让Hibernate可以轻松地自动发现类路径上的@Entity类.然后我使用"factory-bean"和"factory-method"创建一个名为SessionFactory的bean,引用LCEMFB.

使用仅注释方法的一个重要部分是"bean名称"的概念或多或少消失(变得微不足道).

Spring中的"bean名称"形成了对实现类的额外抽象级别.使用XML bean相对于其bean名称进行定义和引用.使用注释,它们由类/接口引用.(虽然bean名称存在,但您不需要知道它)

我坚信,摆脱多余的抽象可以简化系统并提高生产力.对于大型项目,我认为通过摆脱XML获得的收益可能是巨大的.

我认为可见性是基于XML的方法的一大胜利.考虑到用于导航XML文档的各种工具(即Visual Studio + ReSharper的文件结构窗口),我发现XML并不是那么糟糕.

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

我不知道; 最后,XML Hell对我来说似乎并不那么糟糕.