有效管理弹簧依赖关系

-1

我们有一个巨大的Java项目，其中有许多模块导致很多依赖关系。有效管理弹簧依赖关系

假设B依赖于A（一个Spring bean）。

在过去的时间里，我们已经在那里

A的“接口”改变和B停止运行时的工作情况，
A的行为已更改，所以B继续工作，但并不如预期。

如何避免或处理这种情况？我对流程，软件解决方案或指南感兴趣。

来源

2016-02-24 mosquito87

你应该接受一个答案！还是没有任何建议工作？ –

持续集成和测试套件应该是解决方案的一部分。当A改变依赖于A的所有东西时，都会得到重新测试。

接下来要确定什么是公共的（即在其项目之外使用的）已知是公开的，所以每当需要知道的人都知道变化时，就知道。看看你的团队和代码库的分离。 A和B应该由同一个团队处理吗？它们是否应该成为相同代码库的一部分？

来源

2016-02-24 12:08:50

听起来像你需要为项目编写更好的单元测试用例。当组件A更改B的单元测试时应该失败（测试A会自然失败）。我会建议编写好的单元测试用例，因为实际上没有其他方法可以阻止更改请求。

来源

2016-02-24 12:00:09

这不是单元测试，而是集成测试。 – mosquito87

是啊，所以在我看来，你可以使用一个好的单元测试来掩饰依赖关系。你需要为依赖模块使用模拟，这将有助于你。 –

我们有一个庞大的Java项目，有很多模块导致很多依赖关系。

数字1：

根据

到Spring Framework Best Practices：

不要滥用依赖注入：

至于最后一点，Spring的ApplicationContext可以创建Java对象你，但不所有的Java对象都应该通过依赖关系注入来创建。例如，不应通过 ApplicationContext创建域对象。 Spring是一个很好的框架，但是，就可读性和可管理性而言，基于XML的配置在定义多个bean时可能会成为问题。依赖注入的过度使用会使XML配置更复杂和臃肿。请记住，使用功能强大的IDE（例如Eclipse 和IntelliJ），Java代码比XML文件更易于读取，维护和管理！

所以只在有时的情况下使用依赖注入，其他明智的情况会让你的项目混淆。

我对过程，软件解决方案或指南感兴趣。

，如果你决定使用依赖注入，还有一些其他提示：

数2：

身高setter注入了构造器注入：

Spring提供了三种类型的依赖注入：构造函数注入，setter注入和方法注入。构造函数注入可以确保bean不能在中构造成无效状态，但setter注入更灵活，并且可管理，特别是当类具有多个属性并且它们的某些是可选的时。

数3：

如果B1，B2，...，BN取决于A和A已经经常更换，使用工厂类（AFactory）和依赖（BI）s到AFactory豆代替豆的一部分。那么对于创建一个bean的每个更改，只有Afactory会受到影响，而其他Bi bean不会被更改。

A的行为发生了变化，因此B继续工作，但并不如预期。 您可以通过适当的集成测试来控制这些不便。

还应该设计接口，以便每个方法都有一定的明确行为。那么你就可以假设这些方法和行为，并写出B.如此改变A的实现细节，不会影响B的行为，并且很自然的是，如果违反了A的行为，B的行为就会改变。实际上开发人员有责任仔细设计接口并防止出现这些问题。

来源

2016-02-27 13:19:50 Atefeh

有效管理弹簧依赖关系

回答

相关问题