xml – 依赖注入容器的好处是什么?

前端之家收集整理的这篇文章主要介绍了xml – 依赖注入容器的好处是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我理解依赖注入本身的好处。让我们以Spring为例。我也了解其他Spring特性的好处,比如AOP,不同种类的助手等等。我只是想知道,XML配置的好处是什么:
<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

与普通的老java代码比较:

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

这是更容易调试,编译时检查,只有知道只有java的人可以理解。
那么依赖注入框架的主要目的是什么? (或显示其优点的一段代码)。

更新:
的情况下

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

如果有多个IoC框架猜测我想要注入myService的哪个实现?如果只有一个实现的给定接口,并且我让IoC容器自动决定使用它,它将在第二个实现出现后被打破。如果有意地只有一个可能的接口实现,那么你不需要注入它。

这将是非常有趣的看到IoC的小块配置显示它的好处。我一直使用Spring一段时间,我不能提供这样的例子。我可以显示单行,演示hibernate,dwr和我使用的其他框架的好处。

更新2:
我意识到IoC配置可以更改,而无需重新编译。这真的是一个好主意吗?我可以理解,当有人想要更改数据库凭据而不重新编译 – 他可能不是开发人员。在您的实践中,除开发人员之外的其他人多久改变IoC配置?我认为对于开发人员没有努力重新编译该特定类,而不是更改配置。而对于非开发人员,你可能想让他的生活更容易,并提供一些更简单的配置文件

更新3:

External configuration of mapping between interfaces and their concrete implementations

什么是如此好的使它extenal?你不会把所有的代码都外部,而你绝对可以 – 只是把它放在ClassName.java.txt文件,手动读取和编译 – 哇,你避免重新编译。为什么要避免编译?

You save coding time because you provide mappings declaratively,not in a procedural code

我理解有时声明性方法可以节省时间。例如,我只声明一次bean属性和DB列之间的映射,并且hibernate在加载,保存,基于Hsql等构建sql时使用此映射。这是声明式方法的工作原理。在Spring(在我的例子中),声明有更多的行和具有相同的表现力,相应的代码。如果有一个例子,当这样的声明比代码更短 – 我想看到它。

Inversion of Control principle allows for easy unit testing because you can replace real implementations with fake ones (like replacing sql database with an in-memory one)

我理解控制好处的反转(我喜欢调用这里讨论的设计模式作为依赖注入,因为IoC更通用 – 有许多种控制,我们只反转其中之一 – 初始化的控制)。我问为什么有人需要除了编程语言之外的东西。我绝对可以替换真正的实现与假的使用代码。并且这个代码将表示与配置相同的东西 – 它将只是用假值初始化字段。

mary = new FakeFemale();

我明白DI的好处。我不明白外部XML配置与配置相同的代码相比有什么好处。我不认为编译应该避免 – 我每天编译,我还活着。我认为DI的配置是声明性方法的坏例子。如果声明一次AND并且以不同的方式使用许多次,声明可以是有用的 – 例如hibernate cfg,其中bean属性和DB列之间的映射用于保存,加载,构建搜索查询等。Spring DI配置可以容易地转换为配置代码,就像在这个问题的开头,能不能?它只用于bean初始化,不是吗?这意味着声明式方法不会在这里添加任何东西,是吗?

当我声明hibernate映射,我只是给hibernate一些信息,它的工作原理 – 我不告诉它做什么。在Spring的情况下,我的声明告诉Spring完全wht – 所以为什么声明它,为什么不只是做它?

最后更新:
伙计们,很多答案告诉我关于依赖注入,我知道是好的。
问题是关于DI配置而不是初始化代码的目的 – 我倾向于认为初始化代码更短,更清晰。
我唯一的答案,我得到了我的问题,是,它避免了重新编译,当配置更改。我想我应该发布另一个问题,因为它是一个大秘密,为什么编译应该避免在这种情况下。

对于自己,使用IoC(并利用外部配置)的主要原因之一是两个方面:

>测试
>生产维护

测试

如果你把测试分成3个场景(这在大规模开发中是相当正常的):

>单元测试
>集成测试
>黑盒测试

你想做的是在最后两个测试场景(Integration& Black Box),不重新编译应用程序的任何部分。

如果任何测试场景需要更改配置(即:使用另一个组件来模拟银行集成或执行性能负载),这可以很容易地处理(这是受益于配置DI端的IoC。

此外,如果您的应用程序在多个站点(使用不同的服务器和组件配置)中使用,或者在实时环境中具有更改的配置,则可以使用后续阶段的测试来验证应用程序是否会处理这些更改。

生产

作为开发人员,您不会(而且不应该)控制生产环境(特别是当您的应用程序分发给多个客户或单独的站点时),这对我来说是使用IoC和外部配置的真正好处,因为它是由基础设施/生产支持调整和调整生活环境,而不必回到开发人员和通过测试(更高的成本,当他们想做的是移动组件)。

概要

IoC的外部配置的主要好处是给予其他人(非开发人员)配置应用程序的权力,在我的经验中,这仅在有限的情况下有用:

>应用程序分发到多个站点/客户端,其中环境不同。
>有限的开发控制/输入在生产环境和设置。
>测试场景。

在实践中,我发现,即使开发一些你可以控制环境的东西,它也会运行,随着时间的推移,最好给别人改变配置的能力:

>当开发你不知道它什么时候会改变(应用程序是如此有用,你的公司卖给别人)。
>我不想停留在每次请求一个小的改变,可以通过设置和使用一个良好的配置模型来处理代码

注意:应用程序是指完整的解决方案(而不仅仅是可执行文件),因此应用程序运行所需的所有文件

原文链接:https://www.f2er.com/xml/294145.html

猜你在找的XML相关文章