在代码中执行依赖注入配置有什么问题？

Question

XML似乎是当时的语言，但它不是类型安全的（没有外部工具来检测问题），最终你会用XML做逻辑。为什么不用与项目其余部分相同的语言来做。如果它是java，你可以构建一个配置jar并将它放在类路径上。

我一定很遗憾。

Answer 1

代码中配置DI的主要缺点是强制重新编译以更改配置。通过使用外部文件，重新配置成为运行时更改。 XML文件还提供了代码和配置之间的额外分离，这是许多人非常重视的。

这可以使测试，可维护性，远程系统更新等更容易。但是，对于许多语言，您可以使用动态加载有问题的代码并避免一些缺点，在这种情况下优势会减少。

Answer 2

Martin Fowler在这里很好地阐述了这个决定：

http://martinfowler.com/articles/injection.html

避免剽窃的冲动......只需阅读“代码或配置文件”部分。

Answer 3

在代码中进行配置没有任何本质上的错误，只是倾向于使用XML来提供一些分离。

人们普遍认为，以某种方式使用XML配置可以保护您不必在更改后重建。根据我的经验，您需要重新打包和重新部署应用程序以提供更改的XML文件（无论如何都是Web开发），因此您可以轻松地更改某些Java“配置”文件。 Yo 可以将XML文件放到Web服务器上并刷新，但是在我工作的环境中，如果我们这样做，审计将是合适的。

在我看来，使用XML配置的主要原因是迫使开发人员考虑依赖注入和关注点分离。在Spring（以及其他）中，它还提供了一个方便的挂钩来挂起你的AOP代理等。这两个都可以在Java配置中实现，在绘制线条的地方不太明显，并且倾向于重新引入直接依赖关系和意大利面条代码。

有关信息，可以使用Spring project在代码中进行配置。

  

Spring Java Configuration项目（简称JavaConfig）提供了一个类型安全的纯Java选项，用于配置Spring IoC容器。虽然XML是一种广泛使用的配置方法，但Spring的多功能性和基于元数据的bean定义内部处理意味着XML配置的替代方案易于实现。

Answer 4

根据我的经验，开发团队和基础架构团队之间的密切沟通可以通过频繁发布来促进。您发布的越多，您就越了解环境之间的差异。这也允许您删除不必要的可配置性。

这里适用于康威定律的必然结果 - 您的配置文件将类似于您的应用程序部署到的各种环境（计划的或实际的）。

当我有一个团队部署内部应用程序时，我倾向于在代码中为所有架构问题（连接池等）驱动配置，并在文件中为所有环境配置（用户名，连接字符串，IP地址）配置。如果在不同的环境中存在不同的架构问题，那么我将它们封装到一个类中，并使该类名称成为配置文件的一部分 - 例如。

container.config = FastInMemoryConfigurationForTesting container.config = ProductionSizedConfiguration

其中每一个都将使用一些常见配置，但会覆盖/替换需要替换的架构部分。

然而，这并不总是合适的。有几件事会影响您的选择：

1）在每个生产环境中成功部署之前释放新drop后需要多长时间，并且您会收到有关该环境的反馈（周期时间） 2）部署环境的可变性 3）从生产环境中获得反馈的准确性。

因此，当您的客户将您的应用分发给他们的开发团队进行部署时，您将不得不使您的应用程序比您自己推送它更加可配置。您可以仍然依赖于代码中的配置，但这需要目标受众了解您的代码。如果您使用通用配置方法（例如Spring），则可以使最终用户更容易适应和解决生产中的问题。

但一个标题是：可配置性是沟通的替代品。

Answer 5

XML并不意味着具有逻辑，而且它远不是一种编程语言。

XML用于以易于理解和修改的方式存储DATA。

您是否说过，它通常用于存储定义，而不是业务逻辑。

Answer 6

它很糟糕，因为它使测试更难。

如果您正在编写代码并使用getApplicationContext（）等方法来获取依赖项，那么您将丢弃一些依赖注入的好处。

当您的对象和服务不需要知道如何创建或获取它们所依赖的资源时，它们就会更加松散地耦合到这些依赖项。

松耦合意味着更容易进行单元测试。如果你需要实例化它的所有依赖项，很难把东西放到junit中。当一个类省略了关于其依赖关系的假设时，为了测试，它易于使用的模拟对象代替真实对象。

此外，如果您能够抵制使用getApplicationContext（）和其他基于代码的DI技术的冲动，那么您（有时）可以依赖于弹簧自动装配，这意味着更少的配置工作。无论是代码还是XML中的配置工作都很乏味，对吧？

Answer 7

你在对你的问题的评论中提到了Spring，这表明你可能对Spring 3允许你express your application contexts in Java rather XML感兴趣。

这有点像大脑，但是bean的定义及其相互依赖性可以用Java完成。它仍然保持配置和逻辑之间的清晰分离，但线条变得更加模糊。

Answer 8

XML主要是数据（名词）格式。代码主要是处理（动词）格式。从设计角度来看，如果主要是名词（地址，值设置等）和代码（如果它主要是动词（处理标志，处理程序配置等）），那么将配置用于XML是有意义的。