在代码中进行依赖项注入配置有什么问题?

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

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

马丁·福勒在这里很好地阐述了这个决定:

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

避免抄袭的冲动…只需阅读“代码或配置文件”一节。

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

人们普遍认为,以某种方式将您的配置保存在XML中可以保护您不必在更改后重新构建。在我的经验中,你需要重新打包和重新部署应用程序来传递修改后的XML文件(在Web开发的情况下),这样你就可以很容易地改变一些Java“配置”文件。哟 能够 只需将XML文件放到Web服务器上并刷新,但在我工作的环境中,如果我们这样做了,审计将是合适的。

在我看来,使用XML配置实现的主要功能是强迫开发人员考虑依赖注入和关注点分离。在春天(除其他外),它还提供了一个方便的钩子挂你的AOP代理和类似。这两种方法都可以在Java配置中实现,只是在绘制线条的地方不太明显,趋势可能是重新引入直接依赖性和意大利面条代码。

为了获取信息,有一个 Spring project 允许您在代码中进行配置。

Spring Java配置项目(简称JavaCon Fig)为配置Spring IOC容器提供了一种类型安全、纯Java的选项。尽管XML是一种广泛使用的配置方法,但是Spring的多功能性和基于元数据的bean定义内部处理意味着XML配置的替代方案很容易实现。

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

康威定律的一个推论在这里适用——您的配置文件将类似于您的应用程序部署到的各种环境(计划的或实际的)。

当我有一个团队部署内部应用程序时,我倾向于针对所有体系结构问题(连接池等)在代码中进行配置,并针对所有环境配置(用户名、连接字符串、IP地址)在文件中进行配置。如果在不同的环境中存在不同的体系结构问题,那么我将把它们封装到一个类中,并将该类名作为配置文件的一部分-例如。

container.config=fastnmemoryconfiguationfortesting container.config=产品大小配置

其中的每一个都将使用一些通用配置,但将覆盖/替换体系结构中需要替换的部分。

然而,这并不总是合适的。有几个因素会影响您的选择:

1)在每个生产环境中成功部署一个新的drop并收到该环境的反馈(周期时间)后,释放该drop需要多长时间? 2)部署环境的可变性 3)从生产环境中获得反馈的准确性。

因此,当你有一个客户将你的应用分发给他们的开发团队进行部署时,你将不得不使你的应用比你自己推动它更可配置。你 能够 仍然依赖代码中的config,但这需要目标读者理解您的代码。如果您使用通用的配置方法(例如Spring),则可以使最终用户更容易地适应和解决生产中的问题。

但一个要点是:可配置性是交流的替代品。

XML并不意味着有逻辑,它远不是一种编程语言。

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

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

您在对您的问题的评论中提到了Spring,因此这表明您可能对Spring3让您 express your application contexts in Java rather XML .

这是一个脑弯曲,但你的豆类的定义,以及它们之间的依赖关系,可以用Java来完成。它仍然保持着配置和逻辑之间的清晰分离,但是这条线变得更加模糊了。

XML主要是一种数据(名词)格式。代码主要是处理(动词)格式。从设计的角度来看,如果您的配置主要是名词(地址、值设置等),那么用XML进行配置是有意义的;如果配置主要是动词(处理标志、处理程序配置等),那么用代码进行配置也是有意义的。

这很糟糕,因为它让测试变得更难。

如果您正在编写代码并使用getApplicationContext()等方法获取依赖项,那么您将放弃 一些 依赖注入的好处。

当您的对象和服务不需要知道如何创建 或获得 它们所依赖的资源,与这些依赖关系更松散地耦合在一起。

松耦合意味着更容易进行单元测试。如果需要实例化某个JUnit的所有依赖项,则很难将其放入JUnit中。当一个类忽略了对其依赖性的假设时,为了测试的目的,它很容易使用模拟对象代替真实对象。

此外,如果您能够抵制使用getApplicationContext()和其他基于代码的DI技术的冲动,那么(有时)您可以依赖Spring自动布线,这意味着配置工作更少。无论是在代码中还是在XML中,配置工作都是乏味的,对吗?