在一个将于春季前连接起来的类中使用@Autowired的利弊是什么?
为了澄清这一点,我专门讨论的是@Autowired注释,而不是用XML自动连接。
我可能只是不明白,但在我看来,这似乎是一种反模式--您的类开始意识到它们与DI框架联系在一起,而不仅仅是POJO。也许我是一个贪吃惩罚的人,但我喜欢为bean提供外部XML配置,而且我喜欢有明确的线缆,所以我确切地知道哪里是连接的。
发布于 2009-03-11 14:30:36
很长一段时间以来,我一直认为拥有“集中式、声明式、配置”的xml文件是有价值的,就像我们以前使用的xml文件一样。然后我意识到,文件中的大部分内容都不是配置--在开发之后,它从来没有被更改过。然后,我意识到“集中式”只在相当小的系统中有价值--只有在小型系统中,您才能作为一个整体摸索配置文件。当代码中的依赖项大部分复制相同的“线缆”时,理解整体布线的真正价值是什么?因此,我保留的唯一东西是元数据(注释),它仍然是一种声明性的。这些数据在运行时永远不会改变,也不会是某个人会动态更改的“配置”数据--所以我认为将其保存在代码中是很好的。
我尽可能多地使用全自动配线。我爱死它了。除非受到枪口的威胁,否则我不会再回到旧式的春天。我偏爱@Autowired的理由随着时间的推移而改变了。
现在,我认为使用自动装配最重要的原因是您的系统中没有一个需要跟踪的抽象。"bean名称“实际上已经消失了。事实证明,bean名称的存在仅仅是因为xml。因此,一个完整的抽象间接层(您可以将bean名为"foo“连接到bean "bar")消失了。现在,我将"Foo“接口直接连接到我的bean中,实现由运行时配置文件选择。这允许我在跟踪依赖项和实现时使用代码。当我在代码中看到一个自动处理的依赖项时,我只需在IDE中按下"go to implementation“键,就可以得到已知实现的列表。在大多数情况下,只有一个实现,我直接进入了类。没有比这更简单的了,而且我总是知道使用的是什么实现(我声称xml布线与事实相反--有趣的是,您的透视图是如何变化的!)
现在您可以说这只是一个非常简单的层,但是我们添加到系统中的每一层抽象都会增加复杂性。我真的不认为xml为我所使用过的任何系统增加了任何真正的价值。
我曾经使用过的大多数系统只有一种生产运行时环境的配置。可能还有其他的测试配置,等等。
我想说的是,完全自动装配是spring的红宝石护栏:它包含了一种概念,即大多数用例遵循的是一种正常和通用的使用模式。对于XML配置,您允许大量一致/不一致的配置使用,这些配置使用可能/不可能是有意的。我已经看到了太多的xml配置与不一致之处--它是否与代码一起被重构?我不这么认为。这些变化是有原因的吗?通常不会。
我们在配置中很少使用限定符,并且找到了解决这些情况的其他方法。这是我们遇到的一个明显的“缺点”:我们稍微改变了代码的方式,使其与自动装配交互更加顺畅:客户存储库不再实现通用的Repository<Customer>接口,但我们创建了扩展Repository<Customer>的接口CustomerRepository。有时候,在子类问题上也会有一两招。但它通常只是指向更强的打字方向,我发现这几乎总是一个更好的解决方案。
但是,是的,您正在绑定到一种特定的DI风格,这种风格主要是spring所做的。我们甚至不再为依赖项设置公共设置器(因此您可以说我们在封装/信息隐藏部门中是+1 )--我们的系统中仍然有一些xml,但是xml基本上只包含异常。完全自动装配与xml很好地集成。
我们现在唯一需要的是将@Component、@Autowired和其他部分包含在JSR (如JSR-250)中,这样我们就不必与spring绑定。这是过去发生过的事情( java.util.concurrent的东西浮现在脑海中),所以如果这种事情再次发生,我不会完全感到惊讶。
发布于 2009-03-11 03:02:15
对我来说,这是我喜欢/不喜欢的春天和自动布线。
优点:
缺点:
我已经开始使用自动布线,几乎完全是在工作中,因为我们非常依赖Spring集成,所以依赖问题是没有意义的。我从事过一个Spring项目,该项目广泛使用自动布线,有点难以理解。
我认为自动配线是一种后天养成的品味,一旦你习惯了它,你就会意识到,与XML配置相比,使用它是多么的强大、容易,而且也就没有那么麻烦了。
发布于 2010-11-30 13:20:45
在我们的大项目中,我们将从@Autowire切换回XML配置。问题是引导性能很低。自动装配扫描器从自动装配搜索类路径加载所有类,因此,在Spring初始化过程中,很多类都被急切地加载。
https://stackoverflow.com/questions/633158
复制相似问题